Ad blocker interference detected!
Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers
Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.
- Randy Fay, Drupal
- Greg Dunlap, Drupal
- Angela Byron, Drupal
- James Falkner, Liferay
- Paul Orwig, Joomla!
- Paul Vorvick
- ?? (your name here :))
- Jono's book The Art of Community has a full chapter on conflict management (chapter 11)
- Drupal's conflict resolution strategies are being discussed in http://drupal.org/project/issues/governance, especially Community conflict resolution process and technical conflict resolution
- If you're interested in the outcome of the Drupal Governance Sprint, follow the issues in Drupal Governance Issue Queue.
Randy Fay, Drupal
The next couple of days we're going to be trying to improve Drupal's governance. A part of this is conflict resolution. One reason we have poor conflict resolution is we have minimal governance. Can't really do much without a framework in which it fits.
We've been thinking/agonizing over this, and interested in what people have to say. We've learned a lot of good things in the "Asshole" discussion yesterday. Very powerful, very important, very relevant. It's more direct to the problem than the solution. "OK, this is what an asshole is. We don't tolerate assholes." Well… what's the response to that? Identifying the problem doesn't resolve it.
http://lb.cm/conflict - I've proposed a conflict resolution technique as a starter for the Drupal community. Still in beginning stages. Proposed the following:
- 1: When there's a conflict, someone has to create an issue in the issue queue. We use our issue queue for code and lots of other things. People who are either involved in conflict or concerned can do that.
- 2: If this involves something which is illegal/violent/etc. it doesn't belong here. Straight to authorities.
- 3: Each involved party writes two separate comments:
a) Historical facts that explain this is what happened, these are the actions that occurred, divorced from emotions/subjective judgment on those actions.
b) Interpretation/emotional impact of those. (separate)
- 4: Parties meet each other in best venue possible: Ideally, in person, next best is video, next best is voice, next best is IRC/chat, finally email. Might happen with a third person as an observer (not mediator). Idea to allow these conflicts to resolve themselves without exhausting a mediator (we need mediators, but if we abuse them, we won't be able to keep them around).
The problem might be resolved here. It's common that when people hear what the other person experienced, the conflict diminishes. In a number of conflict situations, you yell so loud you never realize what others are experiencing.
- 5: If this doesn't resolve it, contact the Conflict Resolution Group (how big? not sure). This would be a meeting with a mediator and the parties. This aims to result in a plan to move forward.
- 6: Fall to governance structure, which we don't have yet. (Only have "defer to BDFL" as a fallback, and our BDFL does not have the space for it.) Also, deferring everything to one person is a great way to cause burnout.
James Falkner, Liferay.
Most issues we have tend to fall away over time. We're a corporate sponsored open source. We also have a BDFL. Recently had some issues around security. Conflict wasn't around fixing the bugs, conflict was about getting the fixes out to the community "You're holding them back for your enterprise customers." That was actually happening, and still is. Problem is we reacted instead of being proactive. We were essentially holding our community hostage over security issues. We looked at other projects and adopted something around that. If we hadn't done that, we'd still have conflict today.
That was mostly resolved, but we still have other conflicts in our community. We also have little governance; a BDFL and a "community council" like Ubuntu, but no decision-making power.
Curious if we need that. Is it better to have more process or let things settle themselves out?
It's absolutely clear you don't want more process than you need. IOt's a waste.
We have a "benevolent cabal" :) We had a problem with people bitching on mailing list. People who were unqualified were reviewing things, we just close it off, pass it amongst people we know to be qualified.
We have a situation where people get frustrated because we have no governance structure. Some people go away, others get loud.
Most difficult conflicts on social side, not technical.
One thing we do in improve theatre groups is … one of the tendencies is to add more rules to deliberately trip up the people you want out. We're trying to fight that problem. If you create that rule to get that person out, quickly thereafter they'll find something else to do that's similarly horrible. Now a new rule… then you have rulebooks that are 260 pages long and full of minutea.
This comes up in gaming a lot because someone will come up with a great idea, but it runs afoul of rules set up to get someone out 15 years ago who's no longer a problem.
We're working on something you're proposing: a community that acts as observers, mediators, etc. to these issues. Ultimately, have to have more of a general understanding (code of conduct) than specific set of rules.
In a development community of nerds, set of rules never work. First thing I'd do is find the loopholes. I don't even want to break them, I just do it for sport. ;) Guidelines have to be accepted that there's some amount of judgment involved.
We've had good experience phrasing behavious we do want to see, instead of the behaviors we don't want to see. Recently a DrupalCon Code of Conduct.. Draft 1 was about negative behaviors people SHOULDN'T do, community freaked out about freedom of speech, respect of different cultures, etc. Draft 2 was about what we DO want people to do, everyone on board.
We have principles but don't always follow them. One of them is "If you have a conflict, take it offline." We don't prescribe more direct, the better. Take it offline, address it directly with that person. Next step is if you can't resolve that issue directly with that person, and it relates to some kind of formal structure, it should fall under their oversight. Send an email to folks in that leadership team.
We have a lot of people on leadership team who would love to avoid conflict resolution. So a lot of things just stall there. People get frustrated, give up, feel they're not responded to.
We've talked about setting up an "Advisory Council" which is kind of like a mediation board. Different reps from different aspects of community and you can take it before that board and try and get a resolution from them. We don't have a BDFL. Issues where we get bogged down is the details: how do you choose who gets on that board? How do you get someone to serve?
It's like what Greg said about nerd community: when you set up rules, you're screwed.
Yeah, we're not trying to set up rules, but there's no doubt that this is going to be controversial within our community. So many people I've talked to said "I'm so glad I set up governance structure before our community" -- makes things so much easier. We will definitely lose people over this, but ultimately it's better for the community if we lose them. If you're not ok with behaving yourself at DrupalCon, don't come. This will probably result in a short drop-off in contribution, but a long-term gain.
Are you not setting up a panel who can judge a situation?
No. more like giving people the tools to resolve conflicts themselves, and setting up support structure if it fails.
What happened in 1942 when red cross was giving away coffee and donuts. Allies didn't have this kind of thing so it made the US look like they had this cushy situation; lots of pressure on the red cross to stop doing this, and eventually they did.
They were interviewing people *70 years later* that the red cross charged for donuts, because an established rule was established, and then the rule was changed.
Somehow we'll have to choose the people who will resolve conflicts. I don't think any of them will be particularly controversial.
Argument from people we'll use is "we're not babies and we don't need adults telling us how to behave." It's hard because we have limited development cycles. If you're against something, it's in your interest to fight and hold it up. The longer it gets held up, the less likely it is to happen. It's one thing to have a discussion and after a couple of months decide it's not worth doing. But it's another thing fo rsomeone with a lot of time on his hands to deliberately disrupt the process. These are the kinds of things we need to get away from on the technical side.
Good point. These are the structures we put in place for social rules like don't be a racist/sexist asshoels. But technical conflicts is a totally different domain.
And sometimes they're mixed. We had a situation recently about whether a piece of code should get committed or not, and resulted in one member accusing the other about deliberately deceiving people, etc. I was able to address the technical issue very easily, but not the social issue at all.
Resembles principle of filibustering. Wonder if we can explore that as a principle. That could lead us into a political atmosphere where there are lot of resources about how to deal with this kind of problem.
We get ignoring too. People raise the issues to folks and they just don't respond.
We get into filibustering problems because in a "normal" meeting you have a limited amount of time to discuss something, and in the issue queue you don't. Looking into establishing deadlines on technical discussion (could possibly get extended). We've always failed in the past of having someone to make a decision.
Yeah, in filibustering, you get a set amount of time then it goes to a vote. You don't have that online.
One of the things we need to do better in the Drupal community is getting decisions made even if it results in conflict. Not bail on decisions because there was conflict involved.
You have core committers and they're the decision-malers right?
No. They wait for community to come to consensus, then the core committers come in. One thing we're playing with is creating leadership positions "initiative leads" to help w/ decision making, but their authority is questionable. There's a tendency to slap the hammer down too fast, and community is skeptical about their role. Also, since a lot of these people were picked due to their social skills rather than technical skills, don't necessarily have same respect. People who were key members of "do-ocracy"start to feel marginalized.
There can be a lot of skepticism about why certain people were chosen, etc. If you say "we selected these people because they HAVE good social skills" it may forestall some of this. But then again, no one respects management. :)
Path that Drupal's followed has mirrored that of startup. Growth of
We have in-person calls with people to resolve conflict, but after they go and blast you again in the social space. How to deal with that?
Or people who *don't* want to have a call. How do you deal with people who won't engage?
We never figured that out. You can't take stuff off the internet. Work with people one on one, but
We've done situations with "We know that there's a problem, we want to hear about what you think, we're going to go ahead though." Feeling like you were heard tends to cut down on successive noise.
OTOH, we have people that are just "aggressively wrong" and the thing that's worked best is completely ignoring them, send them to a kill file.
The thing I keep hoping is if you apply a consistent way to get policy changed, to get technical conflicts resolved, and to escalate personal conflicts. For the majority of people, the "just raise the volume" approach will go away, because there's a process.
One of the key benefits of figuring that out is that for every person who raises the decibel, there are 5 people who leave. So hopefully one of the 5 people who'd raise the volume won't raise the volume.
There are people who believe the right thing to do and not what the problem child thinks. THought of approaching them to ask them to chime in. Is that bad?
I think it's fine to say "Will you read this and comment?"
Yeah, the "silent majority" is a problem, it can feel lonely being the voice of reason.
You can also invite people who are the decibel people to lower it by making them feel invited and asked for their opinion. Even if it turns out community is against them.
We've had a lot of success with extremely loud, angry people by specifically pointing them to places to contribute that help them improve their situation.
At what point do you give up on someone?
I don't know I've never stopped.
And I've never started.
We had one guy that we were going to kick out, and over time improved. But he's *still* fighting stigma of when he first came in. Need to encourage community to give second chances.
Eventually people usually learn to ignore asshioles. problem is new people coming in.
We had a guy who would come in and close bugs, screw things up. Good intentions, but totally screwing things up. We had a lot of conversations with him, but just because we're open, and a do-ocracy, we don't have an ethical responsibility to include *everyone* like society of a whole. We ended up kicking him out because he was causing *way* more problems than he was solving. He just didn't get it.
A lot of us do feel that we have this obligation to community members, but we really don't. We don't embrace all community members; most will wither in irrelevance. So why do we have obligation to troublemakers?
have a similar thing form he real -life roleplaying group and wanting to reach out to a subculture of subculture. But reaching out to people who are marginalized because they're oppressive.
System of "tiered banning"… three-strikes system proposed at the asshole talk. That system of "there are consequences"