< Akademy | 2013 Revision as of 13:39, 15 July 2013 (view source)Jospoortvliet (talk | contribs)← Older edit Revision as of 15:02, 15 July 2013 (view source) Bedahr (talk | contribs) Newer edit → Line 93: Line 93: * This is a police state! <br /> * This is a police state! <br /> Get over yourself. Get over yourself. + + +Live notes: https://notes.kde.org/p/Nmpm2bA5F8 Revision as of 15:02, 15 July 2013 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 violations of our code of conduct and how we can discourage such activities without hampering constructive criticism. This session is mainly aimed at mailing list, and forum moderators and IRC channel operators, but everyone interested in improving communication within KDE is welcome to join. Primary focus for listowners 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 CoC enforcements begin. What procedures do we follow once these first-line efforts have failed? When should you call in the Community Working Group (CWG), and how does one do that? What can the CWG do? Should this role expand to "enforcement"? What is the role of the e.V. Board? Valorie's thoughts: * new IRC channel for KDE chanops? #KDE-ops perhaps; link to KDE docs about how to conduct oneself as a chanop * new listowners list, or even KDE-leadership list, for all listowners, forum mods, and channel operators 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. 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, it will be time for a formal warning. (by CWG? the Board?) Then and only then is it time to consider expulsion, and how that should be handled. -v Contents 1 Proposal for the very stormy day 1.1 Principles 1.1.1 First principle 1.1.2 Second Principle: 1.1.3 Third Principle 1.1.4 Fourth Principle 1.2 The proposal 1.3 Arguments 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. 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. 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. 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; however, the board has to OK any action of this kind and be informed from the point of the first warning and onwards. Also, the process needs to be documented fully; and the e.V. membership has the right to appoint a committee to review the decisions and actions via these documents afterward (but not interfere during the process?). The proposal 1. warning Once the CWG feels somebody is unwilling to change their behavior after (many) open and friendly conversations, they notify the board that they would like to warn this person. (how much info should they share with the board?) 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 breaks the CoC within 2 months, he/she gets his/her cool down period of two weeks. 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 period of two years at least. Again, the board is informed. 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 breach of our CoC bad enough to ban for a longer time, they are free to do so. 5. Communication Whenever the CWG takes any of the actions described here, they have to inform the board. Upon the more permanent ban, the membership is informed that 'somebody' is banned (?) 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. 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. Live notes: https://notes.kde.org/p/Nmpm2bA5F8 Retrieved from "https://community.kde.org/index.php?title=Akademy/2013/ConflictResolution&oldid=33233" Content is available under Creative Commons License SA 4.0 unless otherwise noted.