Develop a conflict resolution process for community issues

I even can't find what we need to change, seems it's possible to take it as it is

@valthebald I think this goes beyond just "technical issues" - think about the energy around http://groups.drupal.org/node/162604 - having a good mediation mechanism in place might have helped limit the drama surrounding the conversation.

Right, here's a *wonderful* example of where a process around conflict resolution is needed from a community standpoint: #1485886: Approve Downtown Los Angeles group

What happened is, because we don't have any kind of conflict resolution process, about half of the webmasters team, including all of the groups.drupal.org maintainers, got embroiled into this inter-personal issue.

One of the things we should do is try to cultivate excellent folks for this task who are not already heavy laden on the tech responsibility side. Actually, the people skills that go with helping resolve conflicts are often not the ones that our "volunteers with superpowers" have.

For example, you, Greg Knaddison, and myself are the main ones who have all gotten involved in major conflict resolution points in the community at one time or another and we all definitely fall under "volunteers with superpowers." :)

Hm. It's probably also worth trying to analyze why that is. While conflict resolution/diplomacy/negotiation are definitely valuable skills that need to be honed over time, they're also skills more generally available than you'd think given the small crew who normally gets roped into these kinds of situations.

One theory is that the three of us have worked our way up the karma ladder enough so that our words might be seen as carrying more weight than other blue nicknames. Another theory is that we are all nice people who go out of our way to help others, and since our community work has resulted in a higher level of respect/trust among our peers, they seek us out for advice on tough problems. I'm not really sure.

But I think in any event, our traditional "do-ocracy" model isn't going to work for forming this team, nor will simply finding a bunch of people who are savvy with resolving arguments. It probably needs some measure of both trusted community member + gifted at listening/tact/etc.

Here is a first-round rough proposal for discussion. The intent is to keep the conflict resolution team out of most conflicts by promoting prerequisite direct conversations.

Drupal Community Conflict Resolution Proposal

Conflict and disagreement is natural and to be expected and treasured. However, when it becomes inflamed with emotion and negative personal feelings, it can result in damaged people and damaged community. We'd like to find another path.

In general, emotionally charged conflicts result when people view the conflict and their opponents without understanding of the others' viewpoints. A huge percentage of interpersonal conflicts can be resolved or at least calmed simply by attempting to build this understanding of each other as human beings who have rational goals.

I read the following strategy years ago in a book called The Art and Skill of Conversation and when I've stuck closely to this strategy, things have gone well.

1. Agree on the real issue (identify the real issue and then constrain the boundaries of the conflict to something that can be worked with)
2. Agree on the history (the narrative of events)
3. Agree on the facts
4. Interpret the facts (each party can give their own interpretation of what all this means to them)
5. Identify the emotions involved (Express what this means emotionally to each party)
6. Determine a course of action

In general, we don't want mediation to be called into play very often, because it strains and exhausts the mediator, and we'll never have enough resources for that. I propose this process:

1. Each party of a conflict should write two separate emails. The first will express just the history/facts of the situation (not emotions or interpretation). The second will express their own interpretation of these facts and how it affects them emotionally.
2. The parties "meet" with each other in the most personal way possible (in person is best; Skype with video probably second, Skype without third IRC a poor fourth). Standard ground rules should be provided, and an impartial observer (not a mediator) may be recruited by the two parties. The agenda will be to re-hash what was said in the emails, with the objective of understanding the other person as a person and their view of the conflict.

3. At this point, the conflict may be resolved, and no formal action needs to have been taken. If it is not resolved yet, the situation can be escalated to the Community Conflict Resolution Team. If the team chooses to accept the conflict, it will start with updated history/facts and interpretation/emotion summaries provided by the parties, along with a statement from each about the earlier meeting and why it did not succeed. A member of the team will meet with the parties (again, using the best possible communication type) and go through the steps again.
4. If the conflict is considered resolved by the parties, that's good.
5. If the parties to the conflict do not consider it resolved, and they think it has to be escalated, they can request escalation to the Conflict Resolution Team. The team can then decide if this is a conflict which must be resolved through authoritative action somewhere in our community governance structures or not. If not, it will be dropped. If it needs to be escalated, the team will request a decision resolving the conflict from the appropriate quarters in the Drupal community. This, of course, depends on us building policy and governance structures.

Things I like about this:
- The approach is extremely sane.
- It encourages people work issues out themselves.
- I like really spelling out some basic conflict resolution steps for people totally unfamiliar with the process (aka, most people involved in conflicts).
- The Conflict Resolution Team is the last resort, not the party that gets pulled in to every conflict, regardless of how petty.

Things I don't like about this:
- It once again is punting on the topic of what to do in "nuclear" cases (well, not punting exactly, but definitely holds a dependency on a @todo). However, it does get the ball much further than it has been before.
- I don't like doing the "facts / emotions" breakdown by email and would prefer the public issue queue. The reason being is that if communication breaks down, the Conflict Resolution Team is going to be left with only part of a story (though I guess that's true regardless once non-text communication is done). I'd love to hear more about your reasoning for choosing email as the format; I personally would've resorted to email only in "nuclear" cases (e.g. rape/death threats where people felt totally unsafe to talk about it publicly, but then I assume those situations get escalated to the CRT without going through this process).

I probably have other thoughts but am kind of distracted atm. GREAT work, Randy!

This sounds very good to me.

In case this will be discussed and refined more, I'm listing two things that I think may help resolve conflicts.

• Each "side" in the conflict should describe the other party's opinion, in a way that the other party agrees with. (This helps understanding others' points of view, and also helps removing misunderstandings about what the issue at hand.)
• Each "side" in the conflict should state what could make them change their mind on the issue. (This forces each party to consider alternatives to their own opinion and is also useful for finding approaches to move on with the conflict. In case one or both parties don't see any way to change their minds, this is also useful information.)

I think the 1–7 list above works as it is, so I don't want to re-open the discussion just for these items. (If they are not incorporated, they might still be useful for a conflict resolution team.)

The current wording in the charter specifically forbids the CWG from getting involved in punitive action until and unless the conflict resolution process has been followed. Specifically:

Barring extreme cases, the CWG does not respond to requests to ban someone. All conflicts must go through the conflict mediation process first.

So the question then becomes whether or not a person with a racist/misogynist/homophobic blog/twitter account, but who keeps those opinions off of Drupal community properties like d.o and IRC, qualifies as an "extreme case." I would argue that it does not. And I think that if anyone wants to see punitive action taken against another community member, the onus is on them to show that they have made every good-faith attempt to resolve things by themselves before it's escalated to the CWG, and also that the CWG is well within their rights to refuse to hear a case until seeing evidence that this has been done. I strongly believe that everyone, including people with unpopular opinions and terrible social skills, deserves to have the right to defend themselves.

Now, it's a different situation if this person was instead directly engaging with an African American lesbian member of the Drupal community over Twitter, and the only connection between said members is the Drupal community, and that person was calling her all manner of mean names over and over again, despite repeated requests from both the victim and other high-profile community members to leave her the hell alone. I would qualify that as harassment, and thus an "extreme case" that indeed the CWG may be called in to either further assist with mediation or, if that breaks down, make a judgment call on and enforce some kind of administrative action. Because it makes no sense to make someone who's a victim of harassment go through some annoying red tape, when really we just need the abuse to stop.

Does that distinction make sense?

+1 Webchick

There is a grey area between community issues and technical issues that must also be addressed. The two are not always distinct - for example, there are issues of contrib vs. core (sheep tennis... '*BAH*... swat... *BAH*... swat) as well as issues related to direction of Drupal and the many subprojects.

Kind of surprised to see this still sitting here after months.

This is pretty critical for us to sort out.

tagging

Summary

Conflict and disagreement is natural and to be expected and treasured. However, when it becomes inflamed with emotion and negative personal feelings, it can result in damaged people and damaged community. Community issues and technical issues are not always distinct.
The aim is to create a solution for "I'm a local user group organizer, and see a 'forking' of my local user group happening. I've tried to resolve this civilly but communication has broken down entirely. What's my next step?"
The impact of these inflamed disagreements include sapping strength from developers, and making it difficult (and scary) for new contributors to engage.
The suggested method is to:

• Create an issue in the Conflict Resolution issue queue
• Report illegal activity immediately to the responsible governmental authorities for legal followup.
• Each party writes up the history/facts of the situation and their interpretation of how this affects them.
• If it is not resolved yet, the situation can be escalated to the Community Conflict Resolution Team.
• If the parties to the conflict do not consider it resolved, and they think it has to be escalated, they can request escalation to the Conflict Resolution Team.

The Question

We need conflict resolution for community issues as well as technical issues. How should we do it?

Expectations

Conflict and disagreement is natural and to be expected and treasured. However, when it becomes inflamed with emotion and negative personal feelings, it can result in damaged people and damaged community. We'd like to find another path. In general, emotionally charged conflicts result when people view the conflict and their opponents without understanding of the others' viewpoints. A huge percentage of interpersonal conflicts can be resolved or at least calmed simply by attempting to build this understanding of each other as human beings who have rational goals.
Community issues and technical issues are not always distinct. For example, there are issues of contrib vs. core as well as issues related to direction of Drupal and the many subprojects.

The Aim

Create a solution for the use case scenario of "I'm a local user group organizer, and see a 'forking' of my local user group happening. I've tried to resolve this civilly but communication has broken down entirely. What's my next step?" The intent is to keep the conflict resolution team out of most conflicts by promoting prerequisite direct conversations. We don’t want mediation to be called into play very often because it strains and exhausts the mediator, we'll never have enough resources, and it strains and exhausts those involved in the process who are not direct parties to the conflict, but are just trying to do core dev.

The Charter

The Charter specifically forbids the Community Working Group from getting involved in punitive action until and unless the conflict resolution process has been followed.

Barring extreme cases, the Community Working Group does not respond to requests to ban someone. All conflicts must go through the conflict mediation process first.

The Stakes

The Drupal core queue is filled with extremely passionate, intelligent and determined individuals who always strive to solve problems in the best possible way. However, we do sometimes come to disagreements about the best way to approach a particular solution, and when two or more individuals fundamentally disagree, issues can sometimes turn into stalemates; or worse, turn ugly. When this happens, it saps strength from the core development team, and makes it difficult (and scary) for new contributors to engage. One impact of this is slowing Drupal core's development velocity and a number of process improvements have happened to address this. These include:

• promoting Jennifer Hodgdon to Drupal core co-maintainer for version 7 and 8.
• A Drupal 8 feature freeze.
• Issue queue thresholds for Drupal core.
• Granting Angela "webchick" Byron commit rights for bug fixes in Drupal 8.

Without a conflict resolution process, situations have occurred where about half of the webmasters team, including all of the groups.drupal.org maintainers, got embroiled into an inter-personal issue.

The scope of this conflict resolution process

This conflict resolution process is to be undertaken before the Community Conflict Resolution Team can take over. The underlying question is what kind of conflicts are within the scope of this process?
How does this process get involved with conflict resolution regarding community member’s opinions expressed anywhere other than on Drupal properties? Would they find help here? Would the Community Conflict Resolution Team could come into play instead? dddave believes the CCRT shouldn't be a wedge to purge the community from persons of certain (mis)beliefs nor to enforce a certain kind of PC behavior. In the clear case of extreme racism we might be tempted to do something but where to draw the line?


Extreme Cases as referred to in The Charter

Does a Drupal community member who expresses derogatory opinions about the Drupal community or it's members off Drupal community properties like d.o and IRC, qualify as an "extreme case"? Webchick argues that it does not. If anyone wants to see punitive action taken against another community member, the onus is on them to show that they have made every good-faith attempt to resolve things by themselves before it's escalated to the Community Working Group. The Community Working Group is well within their rights to refuse to hear a case until seeing evidence that this has been done.
Everyone, including people with unpopular opinions and terrible social skills, deserves to have the right to defend themselves.

Direct harassment of a community member off Drupal community properties counts as an "extreme case”. The Community Working Group may be called in to either further assist with mediation or, if mediation breaks down, to make a judgement call on and enforce some kind of administrative action.
It makes no sense to make someone who's a victim of harassment go through some annoying red tape, when really we just need the abuse to stop.

Governance

The current linked documents wander into governance issues and the form of any facilitation or mediation representative makes this appear reasonable. Here is the linked content related to governance.
Governance is an active form of collective wisdom about the culture, held and implemented by people. All governance systems should reflect this, and can be evaluated by asking two questions:

1. Does governance represent a collective wisdom about the culture?
2. Is governance being implemented properly by people?

When either or both of these answers is 'no,' it is time to re-evaluate the processes and assumptions of governance.

Human beings require from governance:

1. Structure (Consistency, Rules)
2. Liberty (Freedom, Leeway, Understanding)
3. Moderation of Responsibility (No one should singly bear the responsibility of governance forever)

Governance requires from humans

1. Responsibility (as leadership, as understanding of leaders' role and humanity)
2. Decision to participate (if you are participating, then you are agreeing to be governed)

The Current Method:

The current process has been to assign contentious problems to a 'benevolent dictator' who must then understand both the engineering problem as well as the social one. This places a great deal of responsibility on one person, and violates one of the human requirements of governance.

The Suggested Method:

1. Someone, preferably the parties involved, should create an issue in the Conflict Resolution issue queue. This is normally done by the parties seeking help resolving a conflict, but in the case where a conflict is already affecting others, it can be done by others.
2. If the conflict involves illegal activity such as threats of bodily harm, etc., it should immediately be reported to the responsible governmental authorities for legal followup. We're not qualified to deal with threats of rape, violence, or the like.
3. Options for how parties can write up the sides of the conflict. If this is too sensitive for a public laundry display, the parties can opt to do it by email. It is suggested that boundaries of the conflict are constrained within something that can be worked with.
   • Each party to the conflict could write two comments in the issue. The first will express just the history/facts of the situation (not emotions or interpretation). The second will express their own interpretation of these facts and how it affects them emotionally.
   • Each "side" in the conflict could describe the other party's opinion, in a way that the other party agrees with. This helps understanding others' points of view, and also helps removing misunderstandings about what the issue at hand.
     (This is a summary and so I'm trying to include as much of the information as simply as possible. Itangalo states that he doesn't wish to re-open the discussion just for deciding between these two items. However, that if this is not incorporated it might still be useful for a conflict resolution team.)

   Each "side" in the conflict could also state what could make them change their mind on the issue. This forces each party to consider alternatives to their own opinion and is also useful for finding approaches to move on with the conflict. In case one or both parties don't see any way to change their minds, this is also useful information.

4. The parties "meet" with each other in the most personal way possible (in person is best; Skype with video probably second, Skype without third IRC a poor fourth). Standard ground rules should be provided, and an impartial observer (not a mediator) may be recruited by the two parties. The agenda will be to re-hash what was said in the emails, with the objective of understanding the other person as a person and their view of the conflict.
5. At this point, the conflict may be resolved, and no formal action needs to have been taken. If it is not resolved yet, the situation can be escalated to the Community Conflict Resolution Team. If the team chooses to accept the conflict, it will start with updated history/facts and interpretation/emotion summaries provided by the parties, along with a statement from each about the earlier meeting and why it did not succeed. A member of the team will meet with the parties (again, using the best possible communication type) and go through the steps again.
6. If the conflict is considered resolved by the parties, that's good.
7. If the parties to the conflict do not consider it resolved, and they think it has to be escalated, they can request escalation to the Conflict Resolution Team. The team can then decide if this is a conflict which must be resolved through authoritative action somewhere in our community governance structures or not. If not, it will be dropped. If it needs to be escalated, the team will request a decision resolving the conflict from the appropriate quarters in the Drupal community. This, of course, depends on us building policy and governance structures.

Benefits of the Suggested Method:

• The approach is extremely sane.
• It encourages people work issues out themselves.
• Webchick likes how it really spells out some basic conflict resolution steps for people totally unfamiliar with the process (aka, most people involved in conflicts).
• The Conflict Resolution Team is the last resort, not the party that gets pulled in to every conflict, regardless of how petty.
• It does get the ball much further than it has been before.

Room for improvement of the Suggested Method:

• It once again is punting on the topic of what to do in "nuclear" cases (well, not punting exactly, but definitely holds a dependency on a @todo).
• Each "side" in the conflict should describe the other party's opinion, in a way that the other party agrees with. (This helps understanding others' points of view, and also helps removing misunderstandings about what the issue at hand.)
• Each "side" in the conflict should state what could make them change their mind on the issue. (This forces each party to consider alternatives to their own opinion and is also useful for finding approaches to move on with the conflict. In case one or both parties don't see any way to change their minds, this is also useful information.)

The hook_leader() method:

• A solution might be the creation of a 'hook_leader()' system. This system could be implemented to show the the name of the volunteer appended with '_leader()', so for instance webchick would be webchick_leader().
• hook_leader() can be vetoed by project maintainers at any time. hook_leader() is cycled through a number of different users in a project who have volunteered or were appointed by the project leader, perhaps on a weekly basis or even more frequently. Perhaps this could occur on multiple accounts in a project if needed. This cycling process would be automatic and out of the control of anyone.
• Anyone can reject a request to be a hook_leader() at the nomination phase by the project leader. They must, however, be hook_leader() when the system picks them. Whether they choose to involve themselves in problematic discussions is their choice.
• When this king-for-a-day speaks, it is understood that they represent a voice of authority within the project, and have the ability to take over the conversation and provide a social solution. If they are unable to reach a diplomatic solution they can then assign the issue to the project leader with appropriate documentation in the issue.
• At this point the old system takes over.

Note that the hook_leader() leader has no other implicit power or priviledge; they have only been chosen by the site to be a leader for this time.

For comparison: Technical Conflict discussion

There is a question of how truly independent technical conflicts are from community conflicts.

Develop a conflict resolution process for technical issues proposes a mediation method, using a set of mediators with the ability to escalate issues to Dries for higher mediation.

The technical issues themselves:

The technical issues and discussions that have deadlocked and aren't moving forward any more are usually rather long and complicated. Restating the problem and solutions may be enough on its own to have all parties realize they aren't really in conflict at all.
Only when there is a clear summary of the arguments for all points of view should it be assigned to a "conflict resolver".

What is the way we attempt to resolve these issues?

1. Update the issue summary with a clear, objective outline of where the technical conflict breakdown is. Make sure all parties agree that the summary is reflective of the issue at hand.
2. Hold a "real time" discussion, via IRC, Skype, or some other medium, with the interested parties, including those in disagreement. This streamlines and often improves communication and a solution may naturally emerge more readily than from a non-asynchronous written discussion. Important: Make sure to document the result of this discussion in the relevant issue.
3. If this fails to yield a solution, the issue should next be escalated to the project maintainer, by moving the "Assigned" field. If you do not have permissions to move the "Assigned" field, an e-mail via the maintainer's contact form will do. Or, the maintainers could be pinged in IRC with privs. # Not sure about this. Sounds really annoying. :\ But not sure what else to do. An issue tag, people won't know to check, unless Create a conflict resolution team takes care of it and does the outreach? The tricky part of expanding this method across all projects is that the "Assign to" field is limited to maintainers for a project. There is a social problem of making sure that the community knows about this technique and can use it.
4. The maintainer at that point may do one of a number of things: a) make a decision themselves, b) delegate the decision to another, and/or c) let the discussion continue until date X, if it feels like not enough feedback has been gathered but time boxes the discussion.

Who would the mediators be?

They could be chosen using the following method:
Nearest module maintainer -> Nearest system maintainer -> Release Maintainer -> Dries.
A list of people who volunteer to help out with these kinds of issues might also be added. Mile23 suggests a rotating set of volunteers/appointees created by the project maintainer. Each would be designated as mediators on some short schedule. They would only have symbolic power and if they start showing their badge it's time for the tone to change. Technically, the badge system under discussion could support this, or a listed role as a co-maintainer on the front page, perhaps picked by the maintainer. The point would be to demand a tonal change but not the power to hammer anyone, while also having the structure in place to not burn these people out.

Scope of this method:

This method works well for technical conflicts but community conflicts are different. The policy is great for issues inside one specific project, but does it apply for technical conflicts between multiple projects that have multiple maintainers? Do we escalate to a resolution team? Who makes final decisions in that case? Is there a separate discussion for this?

My Personal Thoughts

The main expectation of the Suggested Method appears to be finding joint agreement and so maintain the community, rather than losing members to angry outbursts. However, it also appears to be ambulance at the bottom of the cliff styles rather than developing good dynamics in the first place. Other discussions on Drupal.org discuss the need for in-depth understanding and high levels of group karma before mediation is possible and how limited this is if it was to be applied generally to problem mediation. There is also the suggestion that every process needs someone(s) able to make a final decision if clear consensus can't be reached or difficult issues end up going to the "do nothing" side by default because no one can break the stalemate. The danger here is that the rush to get to a solution causes the same issues that we're trying to avoid and people leave because they feel their contributions weren't being appreciated or understood.
What is at stake is when an acceptable solution for all parties is not possible, the result is lost time, work, and interest on the part of groups of contributors. Contributors are drained of their energy to give. Probably, projects fracture and communities of non-contributors find themselves with modules that are no longer actively supported. This may have more impacts later down the line.
I am not a contributor but from what I have read so far, there appears to be a lack of a firm strategy regarding what each group were trying to achieve in the first place. For example, are there collective group goals more in-depth than what you see on each module's main page?
At some point the parties agreed with each other, then they diverged. What were their initial collective goals? Why were they dedicated to it in the first place? In my opinion an explicit strategy for a group can help mediate differences between people on the focus for their efforts before things escalate into personal flame wars.
While common ground is useful, understanding differences in opinions and comparing who cares most about what aspects can also be effective with dealing with conflict and this has not been raised yet. Can each party focus on their area of interest? Are there other parties that could be involved to change the scenario and provide a better basis for moving forward?

And now for some more general personal comments from an avid passer-by. Almost certainly these should go elsewhere however they are made within the context of this discussion.

• Why are conversations like this being done in long comment threads rather than within nested, ever more specific book pages? I agree with Webchick that a round up post like this seems to be useful, however I don’t see why it should be required on the Drupal driven Drupal community website, except where it is summarising a series of nested sub-topics. This comment thread links to a variety of other discussions of which I’ve read some of each. When it comes to the next stage of incorporating their content into this round-up (particularly regarding the option of using Facilitators which are well covered in Develop a conflict resolution process for technical issues), a new comment will have to be added to this thread rather than just editing my contribution.
• Drupal has a variety of voting modules yet contributors resort to +1 posts to express their opinions.
• Drupal provides excellent written content management and the ability to create sub-groups on topics easily via Organic Groups yet community guidelines/content are being written in Git as documents rather that sitting on the Drupal site itself. It’s like a bunch of engineers writing their factory code of conduct using welding torches rather than the paper and pens they store in their “Industrial Paper Management Products”.

Each of these points may seem like they shouldn't be here. However, in my books a happy community requires extremely easy methods of understanding what's going on, how to easily contribute and how to disagree with each other within the agreed goals of that group. At the moment, it appears that many of Drupal's discussions are not making the most of the community features of Drupal itself. I imagine this makes it easier for mis-understandings and various comments that may appear out of place to more widely read contributors.

Finally, is this what you meant by summarising the issue so far kattekrab? I've added in the content from most of the rest of the linked documents within the discussion. The ones I have missed so far are:

• edubuntu - Building Community / Conflict / Resolution
• Wikipedia - Art of Competing Hypotheses
• Approve Downtown Los Angeles group
• Conflicts of Interest and potentially Private Benefit / Inurement on the Drupal Association board
• Community Working Group

What would be good to do now?