Akademy/2013/ConflictResolution

Introduction

After 15 years of KDE, our community is now one of the largest in the open source world. Sadly, our problems have scaled just as much; but our processes to deal with them didn't.

In this BOF we want to address this problem by establishing new ways to deal with conflicts in our community. We will be looking at defining a process to deal with unpleasant behavior and how we can discourage such activities without hampering constructive criticism.

The first part of this session is aimed at mailing list, and forum moderators and IRC channel operators. The second part is a proposal on how to deal with the cases where all else has failed.

Notes taken during meeting are here. Text below has been updated following those notes.

Mailing lists, forums, IRC

Primary focus for list owners and Chanops will be prevention. Only once their most important efforts to cool the discussions and channel the discussion into productive conversations have failed do stronger enforcements begin. It was noted in the meeting that, like it or not, the moderators fulfill a leadership role. The Forum moderators are far more aware of this (and more organized in this aspect) than IRC and especially mailing list owners. But there are big differences between channels and people, something perceived as a problem by the BoF participants.

What procedures do we follow once these first-line efforts have failed?

The list owners, forum mods and chan ops should get together and discuss this. Whatever is done should be done consistently. Example: people game the system, act bad on one channel and go to another. This has to be caught.

Decision: The CWG can help catalyze this process. CWG will set up a channel where moderators can discuss things and will urge them to create a set of guidelines a well. If this does not work out, we can discuss this again at Akademy next year and see how we can help them.

Both these places can be used to share information and enforce the catalyst role important in all FOSS leadership. Catalyst: http://freenode.net/catalysts.shtml . The Code of Conduct is a statement of our ideals, which leaders need to model. It is also a standard, which can lead to enforcement if the leadership fails to change the bad behavior.

It was also decided that, for the time being, the CWG will continue to only be guiding and helping here. A role expansion to enforcement is not needed as long as the mods can pick this up themselves.

Other notes

In case there are no moderators around, CWG members should be able to step in (aided perhaps by the sysadmin team). Within the existing charter of the CWG, the cwg is designed as a mediation force. It does not provide a way to take action. Allow the CWG to close the whole mailing list / IRC channel where the flaming is happening for some time. The whole communication channel - not related to a single person. -> Cooldown. Moderators can, once they are back, take appropriate action.

When bad behavior occurs, it's important to keep records: logs and bans in IRC, emails on lists (and privately), and on the forum. (forum team issues several warnings before a ban is considered. forum bans are logged in the backend, together with the reasoning. Indications for the ban can be seen, as such bans don't result in the deletion of posts, unlike spam bans) If the bad behavior doesn't stop, it's time to share the records with the CWG so they can communicate directly with the person.

If that doesn't work we move on to the stormy day scenario.

Proposal for the very stormy day

Sometimes, people aren't nice to each other. Usually this works out: everybody has a bad day sometimes. The CWG is there to friendly talk to people, help them understand our culture if there are clashes. Usually this solves the problem. Sometimes it doesn't. That is what this text is about: how to deal with the least fun part of community. For reference, a situation where this scenario would've been relevant has happened about 3 or 4 times in the last 16 years in KDE. So this isn't something which happens often - it IS something we should have a plan for. Voting on this as e.V. membership during an general assembly (to give a crazy example) is about the worst way of handling it.

Relevant to this is the KDE Forum Policy which is on usually referenced to by the Forum team when they correct mis-behavior with warnings or a ban.

Principles

I'd like to put forward a few principles which, if we agree on them, should make the path to a decision clear and relatively easy.

First principle

We're an awesome community. that is worth protecting.

KDE, as community, has a unique culture. We are not just a random bunch of people: we have a history, collectively. We have goals, ideas about the world, a common view on how to behave and how to work together. Much of this is written down in our 'Code of Conduct' as well as our Manifesto, much of it is also implicit and not written down anywhere. These principles matter to us, written or not. They allowed us to be a successful community and got us this far; and they are key to being the fun and awesome place that we are. Our culture, the way we treat people, the fun we have, this matters. We want to preserve it simply because it is WORTH PRESERVING!

Second Principle

Bad behavior harms the project far more than by just discouraging a single contributor who is mistreated.

Putting down other people and rude behavior doesn't just discourage the people being yelled at; but a lot of others who are watching. KDE is a public place and somebody being rude to somebody else shows onlookers that community members can be treated badly. Potential and current contributors can (and often DO!) choose to not want to be here and leave; or (perhaps worse) copy the behavior which, apparently, was OK. We have as much an obligation to those being mistreated as to others indirectly affected to protect them and keep this a fun place.

See the book 'the no asshole rule'.

Third Principle

It is OUR place, we therefor set the rules; behaving properly is NOT optional.

People frequently being rude to others don't have to be evil: it can be a cultural mismatch, a philosophical idea which doesn't fit with how we, as a community, usually work and think. But this is our community and new (and existing) community members will have to adapt to our way of life. Doing nothing is as much an action (silent approval of misbehavior) as stepping up and protecting those being attacked. So we have to do something when people act against the interest of our community.

Fourth Principle

We don't want to become a police state.

A big part of our community is being open. Dissenting opinions are important, people need to feel free to disagree. Violently, sometimes, that is OK. We sometimes get angry at each other, that is not terrible either. We do not want to set up some heavy rules policing our community, killing honest debate and disagreement.

Fifth Principle

We believe in the good of the people working in our community; We think that misbehavior can be mended. We use a Tit For Tat principle: after the "time was served", the person is back in good standing. We don't exclude somebody for ever. Repent for the sin and then you come back.

The proposal

This is meant as *addition* to the way the CWG work. The CWG has been around for a while, it has build a reputation and trust. It has shown to be good, helpful and not dangerous. This is a good time to give it teeth.

Summary:
I propose to give the CWG the ability to ban somebody temporarily from our infrastructure. The process needs to be documented fully; ; the e.V. Board acts as a place for appeal. The e.V. membership has the right to appoint a committee to review the decisions and actions via these documents afterward.

The proposal
1. warning
Once the CWG feels somebody is unwilling to change their behavior after (many) open and friendly conversations, they warn this person. The warning (to be worded by the CWG) states that if the person does not stop this behavior, a cool down period of 2 weeks will be enforced. This means two weeks no access to any KDE infrastructure.
2. Time-out
if the person doesn't break any rule for 2 months, the process resets.
3. judging
If the person in question continues to behave badly within the 2 month period, he/she gets his/her cool down period of two weeks no access to KDE e.V. managed infrastructure.
4. After the timeout
With the timeout comes a warning that if it happens again within 2 months, he/she will be locked out for a longer period determined by the CWG. As a general rule of thumb, this should be at least 6 months. The board is informed of this.
4. Flexibility
The time-out periods as well as the 2 month periods mentioned above are at the discretion of the CWG. If they deem the behavior bad enough to ban for a longer time, they are free to do so.
5. Communication
Whenever the CWG decides to ban somebody for longer than the ~two week cool down period they have to inform the board.
6. Oversight
From the moment a first warning is given, all communication that the CWG is aware of related to the person in question, be it with that person, of that person on our public channels or about that person (eg with the board or within the CWG) needs to be preserved for audit; for a period of at least 1 year after the last action taken against the person in question. The e.V. Membership has the right to request an audit of these data and the actions of the board and CWG, to be executed by up to 3 people appointed by the membership. This is currently already the case, all CWG communication is stored.

The first place for appeal is the KDE e.V. board. They can bring the problem to the membership, which can demand an audit of the process and decision(s).

Arguments

I'd like to address a few common arguments against the actions above.

• It won't work (technically)
  

It does. Of course, people could try to work around the blocking in various ways. They usually don't: the message is clear. If they do, we simply block them again. If they manage to stay 'under the radar' that means their behavior is corrected, so that is actually not so horrible... But again, this has been shown to work just fine in many other places. No reason to expect that it'll turn into a fight here.

• It won't work (everybody in the community gets angry and disagrees)
  

This is a matter of trust. If we agree on the four principles and trust our CWG there is no reason to get upset when the CWG exercises these powers. Note that it will be very rare to even give a short time-out. In our entire 15 year history we've had to ban about 3 people. And the fact that we HAVE this process acts will hopefully also act as a deterrent, decreasing the frequency of us having to use it.

• We can deal with it differently
  

Clearly not. At some point, there is no other option. Hopefully, however, the fact that we HAVE this process and can clearly warn people about it, will make the chance of this being needed less likely!

• We are an open project, this is censorship!
  

No, this is OUR project. We determine the rules. If somebody wants to be an ass, he/she can open his or her own web log and say whatever he or she wants. Not on our turf.

• This is a police state!
  

Get over yourself.