Jump to content

Akademy/2013/ConflictResolution: Difference between revisions

From KDE Community Wiki
No edit summary
add link to the forum policy
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= 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.
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.
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.
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.
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.


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.
Notes taken during meeting are [https://notes.kde.org/p/Nmpm2bA5F8 here]. Text below has been updated following those notes.


What procedures do we follow once these first-line efforts have failed?
== 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.


When should you call in the Community Working Group (CWG), and how does one do that?
=== 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.


What can the CWG do? Should this role expand to "enforcement"?
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.


What is the role of the e.V. Board?
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.  


Valorie's thoughts:
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.
* 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.  
=== 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.  
When bad behavior occurs, it's important to keep records: logs and bans in IRC, emails on lists (and privately), and on the forum.  
Line 26: Line 28:
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 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?)
If that doesn't work we move on to the stormy day scenario.
 
Then and only then is it time to consider expulsion, and how that should be handled. -v


== Proposal for the very stormy day ==


= 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.


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.
Relevant to this is the [http://forum.kde.org/policy.php KDE Forum Policy] which is on usually referenced to by the Forum team when they correct mis-behavior with warnings or a ban.


== Principles ==
=== 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.
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 ===
==== First principle ====
We're an awesome community. that is worth protecting.
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!
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:===
==== Second Principle ====
Bad behavior harms the project far more than by just discouraging a single contributor who is mistreated.
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.
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===
See the book 'the no asshole rule'.
 
====Third Principle====
It is OUR place, we therefor set the rules; behaving properly is NOT optional.
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.
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===
====Fourth Principle====
We don't want to become a police state.
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.
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==
====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.
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'':  <br />
''Summary'':  <br />
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?).
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'' <br />
''The proposal'' <br />
1. warning <br />
1. warning <br />
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?)
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.
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.<br />
2. Time-out <br />
2. Time-out<br />
if the person doesn't break any rule for 2 months, the process resets.
if the person doesn't break any rule for 2 months, the process resets. <br />
3. judging <br />
3. judging <br />
If the person breaks the CoC within 2 months, he/she gets his/her cool down period of two weeks.
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. <br />
4. After the timeout <br />
4. After the timeout <br />
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.
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. <br />
4. Flexibility <br />
4. Flexibility <br />
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.
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. <br />
5. Communication <br />
5. Communication <br />
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 (?)
Whenever the CWG decides to ban somebody for longer than the ~two week cool down period they have to inform the board.<br />
6. Oversight <br />
6. Oversight <br />
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.
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==
===Arguments===
I'd like to address a few common arguments against the actions above.
I'd like to address a few common arguments against the actions above.
* It won't work (technically)
* It won't work (technically) <br />
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 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)
* It won't work (everybody in the community gets angry and disagrees) <br />
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.
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
* We can deal with it differently <br />
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!
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!
* We are an open project, this is censorship! <br />
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.
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!
* This is a police state! <br />
Get over yourself.
Get over yourself.

Latest revision as of 09:02, 9 October 2013

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.