Create a conflict resolution team

So, I'll carry over some thoughts paraphrased from #1493430-10: [meta] Develop a conflict resolution process for community issues . Sorry, this is a bit rambly.

Overall, I think this is a good idea. Traditionally, the role of community conflict management in Drupal has been carried out by select level-headed individuals who've also moved fairly far up the community karma ladder (presumably because people feel like they know them/can trust them, and also their karma can also wield the clout needed to make a decision sound definitive. But there may be other reasons for this general trend).

In terms of the conflicts that have come across my "desk," they've historically been resolved by a combination of Randy, Greg Knaddison, Dries, and/or myself. I'm sure others do this as well, though... if you're one of them, please speak up! :)

In my experience, however, issues only get escalated when something is at a complete boiling point, and several people ready to either a) walk or b) brain each other. So you're coming in to an already super-escalated situation. And I've found (not sure if others' experience matches) that most often I get roped in by a totally uninvolved party who says "Help!! These people I respect and care about are fighting. Please do something!" rather than the people embroiled in the conflict themselves.

So, extrapolating from that, I think the following things would be helpful:

a) A group of people who are identified as both "safe" and also "willing" to get involved in these kinds of issues. This helps take the burden off of us all as individuals, and also helps provide transparency. I'm not sure what people new to the community do when they feel they're being treated unfairly and don't know Randy, Greg, and Angie are out there. But probably, they leave the community, and then tell 20 of their friends how much Drupal sucks.

b) This group being at least somewhat pro-active in monitoring for conflicts, rather than reactive when thing are brought to their attention. You can be so much more effective at conflict resolution if you catch it early enough that there's still half a chance of people being rational. This means not only monitoring Drupal.org forums, issue queues, and IRC, but also social networks like Twitter (especially Twitter :P~) which is often where these things initially start.

c) A clear, objective process for people to follow in case of community conflict, in order to escalate it to someone with more conflict management savvy/experience. That's being covered over in #1493430: [meta] Develop a conflict resolution process for community issues though so I won't re-hash it here. But note that conflicts can range from rather petty in the grand scheme of things (this guy refuses to follow coding standards) all the way to super serious stuff (rape/death threats). I've just about seen it all in my time here. :\

I don't think we can put together this team like we do traditional teams in Drupal. Traditionally, our team approach is extremely do-ocractic. If there's not a team yet, people are empowered to create one. If there is a team, people are empowered to help them, which generally means they then become part of that team. Only in rare cases (such as the security team) do we apply a curation process. And in this case, where this team would be dealing with sky-high emotions as a matter of course, and the occasional "nuclear" issue as well, I think we might need the mother of all curation processes. :\ (Who is going to do said curation is a fascinating chicken/egg question.)

We also need to allow for the case when someone on the conflict management team is embroiled in a conflict themselves. Speaking as a de-facto member of this team right now, this has happened to me several times in the past year and it's always been super hopeless feeling. a) My moving to Acquia caused rampant distrust in certain elements of the community about my motivations and who is ultimately pulling my strings and why, b) sun and I just about came to blows over distribution listings back around xmas time, and c) the docs team and I got into heated discussions about the DA's allocation of resources to Drupal.org, etc. All of which had me at varying points frustrated/depressed enough to seriously consider alternate career paths. :P This stuff comes up, and it's ok, but there absolutely has to be a way for someone on this team to get support, because it happens to them, too. :)

We also need to recognize that the Drupal community is not that big, and it's not uncommon to find yourself in the position of being asked to assist in a situation that one of your co-workers is involved with, or someone you've been friends with for a long time, etc. I had to recently decline a request to get involved in a community conflict involving the security team, because Greg Knaddison and I work for the same company. I didn't feel remotely comfortable being put into the position of having to make a subjective call that would result in me either coming down against a co-worker or else turning it into an Acquia conspiracy. :P An objective conflict resolution process to follow would've helped somewhat, but so would have a group of people I could've pointed this individual to. We should definitely think about how this team should deal with conflict-of-interest issues when they inevitably come up.

With #1485886: Approve Downtown Los Angeles group barely behind us, I'm doubly convinced that our local group needs an open governance policy and I've recently proposed such a policy at http://groups.drupal.org/node/230018

Part of the policy proposal is to have a clear path for reaching out to a facilitator in cases of conflicts between people that can't be resolved privately and professionally. Count me in as being acutely interested in how this issue unfolds and who makes up the conflict resolution team.

+1

[edited to point directly to the node ID.]

I think having people who would join a "Conflict Resolution" team should have some 3rd-party training which certifies them as a conflict resolver.

Not to say that it needs to be in-depth training, but something where we can say, "This person attended a course on conflict resolution which taught them how to peacefully resolve issues in the community." Or something like that. I'm not really sure who does that though, http://odr.info seems to have some stuff.

I'd also say, limiting the team to no more than 1 person from a company would be a good idea, just to avoid the idea that anyone was promoting their personal/company interests over the good of the community.

I'm disinclined towards something like certification, because then we'd need to do some kind of validation of that certification, and also to do various checking to make sure people actually passed it. That's time that could better be spent putting out fires here in our community, IMO.

I think the spirit of your suggestion though is that we should make sure that people who come to this team can demonstrate previous experience with conflict management. I wonder if something like a nomination "signed off by two peers" process + 2-3 specific issue queue references demonstrating one's conflict management skills in action would be sufficient? Hm. Not sure that's actually less work on the verification side, but it would demonstrate a bit more direct relevance to the task at hand, perhaps.

And I really, really don't like quotas. I think they unfairly punish and place limits on workers from pursuing employment that meets their personal, professional, and community goals. There are extremely few individuals in our community who are gifted with conflict management skills, and we want the best people for this job, period, regardless of who pays their bills. To address your concerns, I would much prefer a process for someone who sees a clear conflict of interest to absolve themselves from the situation and get a "sub" in. Or, if someone viewed, say, myself or greggles acting in Acquia's interest instead of the community's, they could raise the concern through the standard conflict resolution process, and it would obviously be dealt with by someone else.

Whatever the result, KISS should have been applied to it.

I am also not sure what kinds of conflicts should be resolved by such a team.

Got some examples?

#1485886: Approve Downtown Los Angeles group is one existing example.

Some hypothetical ones:

A company is putting articles on Planet that have some useful information but also are nearly advertisements. There are some complaints and the feed is pulled. The company gets upset because they say the information is relevant and should be allowed. Neither side backs down. Who decides?

A maintainer of a popular module has no time for it but refuses to let anyone else help. Tons of patches sit in the queue, ignored. The users are complaining. Someone qualified steps up to co-maintain but the maintainer refuses and says he'll get to it when he's ready. The other party is on the verge of forking the module. Should the other party be allowed to take over the module?

A long time good standing member of the community hits burn out and starts turning on the community and acting inappropriately in the forums, groups, and queues. Should he be banned? Who can defuse the situation?

I'm sure there are plenty more but that's off the top of my head based on things that have happened in the past.

@rfay Issues do have most of the things in place needed, however what's to stop disputants from marking issues as "resolved". We could have guidelines around that, but issue queues are often getting mismarked for one reason or another. Not saying it couldn't work, but it's going to make it a little difficult for a conflict mediator to enforce all the steps in the process.

@webchick I agree that "certification" may be overboard, but some process to ascertain that someone has some experience resolving conflicts should be mandatory, perhaps using the method you suggest.

I also agree with Randy that disputants should bring their issues to the moderators, not the other way around, and that the moderators should be people who have time on their hands (here at Kiva, with our online volunteers, we ask that they can give us at least 5 hours a week, just having an ask for a time commitment up front is helpful).

As for the company quotes, well, as long as you have conflicts that involve conflict of interest with companies, if those people are allowed to influence a conflict resolution in which they may have an interest, then you're going to have people abandoning the process because it's perceived as unfair (and it could very well be if you don't act quickly to remove those with a conflict of interest). I don't disagree with you that the best people are often at some of the big companies, but they are never going to have a truly objective opinion in a conflict which involves their company, so you'll have to have some process around ensuring the moderator is independent of an issue.

One last suggestion, have we considered at all of asking DA if they could find a professional conflict mediator who could be used when the situation warranted. Seems like you could get away with paying someone for 10 hours a month or so to work through issues. Possibility of fundraising for such a person as well. That probably doesn't seem too palatable since it's outsourcing, but at least then you could always say the process was being handled by people independent of the issue at hand.

The DA solution isn't really doable, since that would mean the DA is getting involved in core development, which is specifically against their charter.

An issue queue's actually not a terrible idea on the face of it, especially in the interest of KISS. We could even just use this one, and name a component "Conflict resolution request." That'd make it really easy to spin off sub-issues for "Make a policy about X" if we needed. coderintherye's not wrong to worry about malicious status changes, but we have to deal with that in all other issue queues too, so I think it would be ok. Just as anyone can be a douche-bag and set an issue to "fixed" anyone else can also set it back. Eventually, either someone will get tired, or forced into a time-out ban. :)

It's also a fair point that asking this team to be on top of all conflict happening anywhere on the Internet is not remotely realistic; I was merely trying to point out that a) not all conflict originates in places here on Drupal.org (really, seriously, eff Twitter), and b) often huge conflicts can be mitigated before they become "a thing" if you are able to nip them in the bud early. But it's very true that if the conflict resolution process/team is made clear, it opens the door for other random community members to find this stuff for the conflict resolution team, and escalate as needed.

Up-front time commitment requests is a really good idea. I'm not really sure how to remotely estimate that though. My community time spent on conflict resolution can vary from spending 0 hours for 3 months to spending 40 hours in two days. It really depends what's going on, and how bad it is. But setting an expectation of 10 hours/month or so would probably be my guesstimate for an average.

As for this:

"As for the company quotes, well, as long as you have conflicts that involve conflict of interest with companies, if those people are allowed to influence a conflict resolution in which they may have an interest, then you're going to have people abandoning the process because it's perceived as unfair"

Yes. I absolutely, 150% agree that people who work for $company should not be resolving conflicts that have something to with $company. I actually gave a real-world example in #1 of where I have personally recused myself from mediating in a particular conflict for this reason (though it was probably going overboard). But having some kind of mechanism for raising and resolving perceived/potential conflict of interests within the conflict resolution team is an entirely different thing than saying "Sorry, Angie and Greg. We already have one Acquian on team (Dries) so you are not allowed to participate as conflict mediators, despite the fact that you two have already playing this role on a grassroots basis in this community for the past 5+ years." See what I mean? :)

Conflicts of interest can happen for all kinds of reasons that have nothing to do with what company someone works for. I might be friends with someone in "real life" and that could bias me towards their side in an argument. Someone might be a client, or a former client, or a former co-worker who I feel some financial/emotional burden to support. I might completely, empatically disagree with the politics of a person and it clouds my judgment of their situation. Etc. Rather than enforcing quotas around employers, which completely debases my skills and qualities as a human being and reduces me to a faceless drone for whom someone signs my cheques, not to mention severely limits the pool of available moderators (case in point: 3 of the 4 people I listed in #1 as known community conflict resolvers work for Acquia), we're much better served by making sure there's a way for a) someone on the conflict resolution team to recuse themselves from a conflict where they perceive they might have a conflict of interest and b) for someone else to strongly suggest that a team member ought to recuse themselves.

I hadn't considered reaching out to the DA yet on this. I think I would prefer to see how far we can get on our own as a community first before we pull in professional help. Baby steps. It's not so much the "outsourcing" angle that worries me, but more that the really explosive situations I've been involved with require extremely delicate handling and in-depth understanding of the personalities/motivations/backstory involved, which can be difficult to impart effectively to a third party. It might not be a terrible idea from the training angle, though. I know I certainly wouldn't have any idea how to train someone on how to resolve conflicts, even though I do it a lot. :)

Per #9, I don't see this team getting involved in technical debates, really. That's what #1493428: Develop a conflict resolution process for technical issues is for. This team would almost exclusively be about community disputes, I imagine, and the only way I could see this team getting involved in core would be if the situation was so bad that none of the existing core maintainers could solve it. And in such a case, it would be much more about getting the people side of thing working smoothly again rather than making a technical decision.

On this note of resolving conflicts, this just came through the wire and thought it's a useful share for this discussion, from the Perl developer's list:

http://rjbs.manxome.org/rubric/entry/1959

If Angie's ok with using issue queues (I'm ok with it, I think Randy would be a +1 as well since he suggested it), I say we come to a consensus on that, then all we have to resolve is how to vet and designate conflict mediators.

Moving to the new Drupal Community Working Group issue queue.

This might effectively be "fixed" with the foundation of this group, but leaving open for now, until #1493430: [meta] Develop a conflict resolution process for community issues is resolved.

Short link for this group: http://bit.ly/workinggrp

We have some work in progress linked to this google doc..

I would love to help here if possible. I would have to do a lot of searching to find my certifications (and cannot recall specifics) but I was in law enforcement for several years and learned a lot about conflict resolution there.

I am catching up on this topic as there are several related issues. Once I catch up I will try to offer any thing I can to help.

Thanks!

Marking this as "fixed" because we have both a Community Working Group and a Conflict Resolution Policy.