Proposal for procedures regarding CoC actions
I would like to make a procedural proposal based on the ideas emerging from the other python-committers discussion regarding the two month suspension of Github project access for a developer who was posting non-productively.
It seems that there is general agreement to differentiate commonplace list moderation actions from CoC actions which are more of a nuclear option to be reserved for egregious cases of harassment and abuse.
Also, there is general agreement not to concentrate that power in the hands of a single person and that we should have some principles and procedures in place.
I propose that when someone thinks there is a problem serious enough to warrant a Code-of-Conduct action, that it get referred to a group of three people to make the decision. Two of those three people should be long-term, senior, and respected core devs who have good knowledge of the community (Brett Cannon, Nick Coghlan, Antoine Pitrou, et al). The third person should be someone who is also well-respected but more independent and who has more experience in sociology and community management issues (Alex Gaynor or Carol Willing come to mind).
To prevent endless bickering and sharing of sensitive details, the group's decision should be considered settled business which can only be overridden either by an appeal to the PSF board or by the BDFL. When possible, the affected person should be contacted and given an opportunity to defend themselves. The decision shall be announced on python-committers with an overall rationale but without personal details.
The group shall consider the needs of the community first and foremost, and secondarily shall prioritize being as respectful as possible to all parties, and thirdly shall do whatever they can to mitigate the harm to the violator. The actions shall be taken with an intent to protect the vibrancy of the Python community rather than with an intent to punish, humiliate, or discredit the affected person. When possible, some path to redemption or forgiveness shall be offered.
Respectfully submitted,
Raymond Hettinger
On Sat, Apr 1, 2017 at 7:07 PM, Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
I propose that when someone thinks there is a problem serious enough to warrant a Code-of-Conduct action, that it get referred to a group of three people to make the decision.
This reminds me of https://en.wikipedia.org/wiki/NKVD_troika.
On Apr 1, 2017, at 5:21 PM, Alexander Belopolsky alexander.belopolsky@gmail.com wrote:
I propose that when someone thinks there is a problem serious enough to warrant a Code-of-Conduct action, that it get referred to a group of three people to make the decision.
This reminds me of https://en.wikipedia.org/wiki/NKVD_troika.
Well, they both have in common the number "three" :-)
There are however a couple of minor differences:
One was tasked with "screening the peasant population of the entire Soviet Union" for the express purpose of "the liquidation of the kulaks as a class".
The other is tasked with handling rare one-off situations where the stated goals are considering the needs of the community, being respectful as possible to all parties, and doing what they can to mitigate the harm to the violator. The express intent is to protect the vibrancy of the Python community rather than acting with an intent to punish, humiliate, or discredit the affected person.
Other than than those minor differences, it is basically the same thing ;-)
Raymond Hettinger
On Sat, Apr 1, 2017 at 8:43 PM, Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
- The other is tasked with handling rare one-off situations where the stated goals are considering the needs of the community, being respectful as possible to all parties, and doing what they can to mitigate the harm to the violator. The express intent is to protect the vibrancy of the Python community rather than acting with an intent to punish, humiliate, or discredit the affected person.
Well, on the scale of things, the population of USSR in 1937 was 170 million and the number of people tried by the troikas was at highest estimates around 700,000. That's a lot, but still less than 0.5%. Trust me, people serving in troikas had sincere believes that they were protecting the vibrant new community from those seeking to enslave people.
Luckily, in the Python community, episodes that require repressive actions are rare enough that they can be dealt on a case by case basis without causing much distraction. There is no need to over-formalize the process.
On Sat, Apr 01, 2017 at 09:39:36PM -0400, Alexander Belopolsky wrote:
Luckily, in the Python community, episodes that require repressive actions are rare enough that they can be dealt on a case by case basis without causing much distraction. There is no need to over-formalize the process.
"Over" formalize, of course not. We don't want an excess of bureaucracy, but who is to say that Raymond's suggestion is an excess?
Let me preface this by saying that 9 times out of 10, I read the first few lines of Wes' emails and hit delete. And the other time I just hit delete. I find his posting style annoying and pointless: if there's anything of value in them, I can't see it because he doesn't leave enough or any context. And frankly, I support Brett's decision to give him a temporary ban for (apparently) using the Python/Github infrastructure as a personal notepad, wasting people's time.
If that were all Brett had done, I would think "Job well done" and move on.
But he didn't. He labelled Wes a CoC violator, both privately and in public, for something which is a violation of the CoC only by *really* stretching the definition. I mean, come on now, insufficiently respectful of people's time? How Orwellian can you get?
I think that's a mistake. A small mistake, to be sure, and I don't intend to crucify Brett over it. Brett generally does a great job. But small mistakes grow to big mistakes, and I think that this demonstrates that Raymond is right, we do need *some* oversight and process before labelling people a CoC violator and kicking them out on that basis.
I am concerned about the scope-creep and over-use of the CoC nuclear option. This is not the first time either: in my opinion, the proponents of the CoC have consistently promised not to do certain things, then done so. They promised not to unilaterally add the CoC to mailing lists without consultation, then did so. They promised not to use the CoC to ban people for trivial offenses, and have done so.
I shouldn't need to say this, but for the avoidance of doubt I DON'T see this as part of some disastardly plot by the forces of multi-culturalism to suppress dissent. I don't think Brett and others are bad people intentionally excluding different viewpoints. I think that their intentions are good.
So please don't read this as a total condemnation or censure of Brett. I think he was well within his authority as admin to apply a temporary ban to Wes. Where I think he overstepped the boundary was by labelling it a CoC violation. Words do matter, and while I appreciate this is not the same sort of harm as labelling somebody a paedophile or sex offender, "banned for violating the CoC" is not something we should say lightly.
Over on Python-Ideas, I've just responded negatively to a technical suggestion by Ram Rachum. In my opinion, Ram has a habit of making poorly thought-out, superficially-useful suggestions which are invariably rejected. Should we hit him with the hammer of "Code of Conduct violation" for being insufficiently respectful of people's time?
A lot of people probably think that *my* posts are excessively pedantic, detailed and verbose. Including this one. I've been told off (off-list) by at least one senior developer for being too long-winded. Is that a CoC violation?
Based on the precedent now set by Wes' ban, the answer could be Yes. Is that what the community wants? Is that a good way to encourage a diversity of viewpoints and people?
I don't think so.
I don't see any malice in Brett's actions, I think it was just a miscalculation. But it normalises the use of CoC for a trivial offense that could be handled another way. It really should be a big deal to ban somebody for persistent violations of community standards, something we only apply to persist griefers, trolls, racists or sexists who insist on using the Python mailing lists etc to promote their hateful ideology, not just somebody who is apparently just socially awkward.
In a way, what Brett did is a bit like using anti-terrorism legislation against Wes for littering. You see, when he tossed that empty packet out of the car window, people might have thought it was hiding a grenade, and that makes it terrorism.
So I support Raymond's suggestion. I think this demonstrates that good intentions alone are not enough, we need a formal process to prevent CoC from being (unintentionally) abused, to prevent people being labelled as "CoC violators" for merely being a little *too* diverse.
-- Steve
On 2 April 2017 at 14:27, Steven D'Aprano steve@pearwood.info wrote:
But he didn't. He labelled Wes a CoC violator, both privately and in public, for something which is a violation of the CoC only by *really* stretching the definition. I mean, come on now, insufficiently respectful of people's time? How Orwellian can you get?
I think this is the point of disconnect, as is Raymond's description of CoC actions as "more of a nuclear option to be reserved for egregious cases of harassment and abuse."
I'll say it right here: I *have* violated the Python CoC, especially if you go back and look at discussions like those around the decision to move away from open source Mercurial hosting to a proprietary git hosting service. Many of the comments I made during those discussions were *far* from being respectful or kind, and it took a long time for me to become open to the idea that helping core developers spend less time on CPython infrastructure maintenance or fighting with inadequate ad hoc tooling might be a higher priority goal than helping to encourage the use of version control tools and service that happen to be written in Python.
When that kind of thing happens, it's usually because I was sufficiently annoyed that I didn't go through my usual routine of proofreading my emails and figuring out how to replace all the second person pronouns with first person ones and otherwise filtering out the unproductive noise that can get in the way of people understanding the point I'm attempting to communicate. That step takes deliberate effort on my part, but is paid back many times over by reducing the number of pointless side arguments I'd otherwise get myself into. Proofreading is also the point where I may decide not to send a particular message at all, or switch it from a public rebuke to a private reminder of more appropriate behaviour.
As far as I can tell, folks just tend not to remember those incidents for long because:
- they're significantly outnumbered by the occasions where I was able to communicate effectively and help other people achieve *their* goals (or at least help them gain a better understanding of why their goals may be unachievable)
- once I calm down, depending on the exact circumstances, I'll sometimes explicitly apologise for the lack of restraint I exhibited
Whenever we anchor ourselves in an essentialist mindset of "basically good people with good intentions will never violate a CoC out of ignorance or as an emotional outburst", then it makes it *really* hard to apply gentle nudges early in the process where we point out borderline or outright unacceptable behaviour to people, and ask them to apply self-moderation techniques to help provide a more enjoyable environment for everyone else. It also makes it much harder for us as individuals to say "That was an error on my part, I apologise, and I will continue to strive to do better in the future".
And from the point of view of the impact on folks suspended and/or banned, "I got suspended/banned from <channel> due to my inability to follow explicit directions regarding my communications style" doesn't seem to me all that different from "I got suspended/banned from <channel> due to my inability to be respectful and kind towards my fellow participants".
That said, for the benefit of channel moderators, I do think it would be a good idea to define a shared set of explicit "Rules for Active Participation" that are distinct from the more general Code of Conduct, and are explicitly noted as being handled through moderator actions focused on providing a productive collaboration environment.
For example:
- PSF provided communication channels, such as mailing lists, issue trackers, and code repositories, each exist for a particular purpose. While initial off-topic posts will be met with a gentle redirection to a more appropriate location, persistently posting off-topic items will be grounds for suspension at the discretion of the moderators of that particular communication channel
- Messages are posted to be read by others, so it's important to be respectful of the time and energy of readers, and have a clear purpose in posting (e.g. asking a question, answering a question, clearly reporting a problem, proposing a solution to a problem, clarifying a point of confusion), rather than merely posting for the sake of posting. As with off-topic posts, persistently disrespecting the time and energy of readers will be grounds for suspension at the discretion of the moderators of that particular communication channel
- Quietly observing the available public communication channels without actively participating is always an option
- Keep in mind that neither the PSF nor any of the community channels it provides offer any form of commercial customer support. Rather, all communication channels are provided for the benefit of community contributors and potential future contributors
- Also keep in mind that there's a lot more to the internet than just the PSF provided communication channels. Personal blogs, social media, code hosting services, etc, can all provide a way to collect and publish material that isn't considered suitable for any available PSF provided channel
- When in doubt about the appropriateness of a message, some good
ways to resolve that doubt can be to:
meta-discussion regarding appropriate use of the list
- spend some more time observing the communications channel in question, perhaps by browsing the archives of past messages
- for mailing lists, explicitly *ask* the question that is concerning you, as most mailing lists allow for at least some
- for issue trackers and code repositories, look for a suitable venue (such as a related mailing list) to ask the question
- if you already know other participants in the channel, ask them for private feedback first
The "be open, respectful, and kind" guidance in the CoC would then mostly apply to the channel moderators responsible for enforcing those Rules for Active Participation, since CoC violations on the communication channels themselves would *also* break the suggested rules 1 & 2 above (by being both off-topic and disrespectful of readers time and energy).
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 2 April 2017 at 06:59, Nick Coghlan ncoghlan@gmail.com wrote: [...]
And from the point of view of the impact on folks suspended and/or banned, "I got suspended/banned from <channel> due to my inability to follow explicit directions regarding my communications style" doesn't seem to me all that different from "I got suspended/banned from <channel> due to my inability to be respectful and kind towards my fellow participants". [...]
In principle, I agree with pretty much all of what you said. However, the one point I disagree on is that describing someone as having violated the code of conduct is no big deal. In your quote above, you avoid the term "Code of Conduct", and I think that's pertinent.
While the Python community is the focus here, I think it's naive to ignore what other parts of the technical community, and even wider observers of that community, think. From what I can tell, people in general are aware that the technical community has identified an issue with how we handle diversity - openness to contributions from people outside of the "white male technical geek" stereotype. The means that technical communities have chosen to address that issue is perceived as the adoption of explicit codes of conduct that clarify that exclusive behaviour is unacceptable, and not to be tolerated.
As a result, the public perception of a "code of conduct violation" is that someone has harassed, or otherwise made a community member uncomfortable, specifically because they don't conform to the stereotypical norm. That's not necessarily what any specific code of conduct might say, but it's how the public perceives such things (and high-profile blog entries that expose exclusive behaviour, and cite codes of conduct and how they help and where they fail to, simply reinforce that perception).
We may not like the fact that a simple term like "Code of Conduct" gets appropriated in the public perception in such a way, but denying the reality of it doesn't mean it doesn't happen.
As Raymond said, the health of the community must always come first, and respecting all parties second. But we should *also* ensure that we don't inadvertently harm the perpetrator of any violation - and to my mind, referring to their behaviour using a term that means something much more serious outside the Python community than it does internally[1], is precisely the sort of inadvertent harm that we can, and should, avoid.
Certainly, sometimes people are annoying, or are idiots. I know I can be. Certainly, some people are persistently like that, and that's a problem. But *anyone* can be like that - not just white, male technical geeks. In my view, the point of the CoC should be that we deal with everyone equally and respectfully, *including* how we deal with them when they are being annoying idiots. And that means that we need processes for handling such people that we can apply within the context of our commitment to inclusivity (to the extent, for example, that we have to be *really* careful to ensure that we don't mis-characterise genuine behavioural issues as "being an idiot", but we still have means to help people with behavioural issues to interact effectively with us). Moderation processes need to work alongside the CoC, rather than being subsumed by them.
In summary, though, I think the issue here is simply one of how we describe things. I think that as a community we do a good job, and we're continually seeking to do better, which is great. But perception is key, and terms can be loaded in ways that we may not agree with, but have to deal with.
Paul
[1] And I think that one of the clear points from this thread is that even internally, perceptions are not all the same.
Here's a step-by-step guide of how things would be handled with Raymond's proposal -- which seems reasonable to me, BTW -- and can act as an initial draft of what we can put in the devguide:
A person is warned that they are violating the CoC by the moderator of the resource being used and it is explained to them how they are violating it in hopes that they change their behaviour
Depending on the severity of the violation, the person in question may receive multiple warnings until they are told that one more violation will lead to a temporary ban
If the person violates again after their final warning, the moderator of the resource being used has the right to temporarily ban the violator from the resource for a length of time of their choosing, but no more than 3 months they disagree? PSF board?
- XXX or some length of time we all are comfortable with that doesn't require creating a panel like permanent banishment does;
- XXX and who can the person who is temporarily banned appeal to if
When the person who was violating the CoC is allowed back into the resource, if they violate the CoC I permanent ban may be considered by convening a panel of three people to decide if a permanent ban is necessary python-committers recording that the banishment has occurred and
- If banishment occurs, it will be followed with an email to
who formed the panel in making that decision 2. The person who has been banned may appeal to the PSF board if they disagree with the ban
The moderator of the resource reserves the right to request from the PSF board a ban from all PSF-controlled resources if the violations of the CoC are deemed severe enough
- Banishment from two separate resources will automatically trigger a request of the PSF board to ban the violator from all PSF-controlled resources
On Sun, 2 Apr 2017 at 04:34 Paul Moore p.f.moore@gmail.com wrote:
On 2 April 2017 at 06:59, Nick Coghlan ncoghlan@gmail.com wrote: [...]
And from the point of view of the impact on folks suspended and/or banned, "I got suspended/banned from <channel> due to my inability to follow explicit directions regarding my communications style" doesn't seem to me all that different from "I got suspended/banned from <channel> due to my inability to be respectful and kind towards my fellow participants". [...]
In principle, I agree with pretty much all of what you said. However, the one point I disagree on is that describing someone as having violated the code of conduct is no big deal. In your quote above, you avoid the term "Code of Conduct", and I think that's pertinent.
While the Python community is the focus here, I think it's naive to ignore what other parts of the technical community, and even wider observers of that community, think. From what I can tell, people in general are aware that the technical community has identified an issue with how we handle diversity - openness to contributions from people outside of the "white male technical geek" stereotype. The means that technical communities have chosen to address that issue is perceived as the adoption of explicit codes of conduct that clarify that exclusive behaviour is unacceptable, and not to be tolerated.
As a result, the public perception of a "code of conduct violation" is that someone has harassed, or otherwise made a community member uncomfortable, specifically because they don't conform to the stereotypical norm. That's not necessarily what any specific code of conduct might say, but it's how the public perceives such things (and high-profile blog entries that expose exclusive behaviour, and cite codes of conduct and how they help and where they fail to, simply reinforce that perception).
We may not like the fact that a simple term like "Code of Conduct" gets appropriated in the public perception in such a way, but denying the reality of it doesn't mean it doesn't happen.
[SNIP]
In summary, though, I think the issue here is simply one of how we describe things. I think that as a community we do a good job, and we're continually seeking to do better, which is great. But perception is key, and terms can be loaded in ways that we may not agree with, but have to deal with.
Assuming the outline of procedures I wrote up above is fine, what about people like Wes who are consistently unproductive participants and thus are IMO being disrespectful of others, just not in an overtly rude way? Do we open with a sentence saying "In the steps below, a 'bad actor' is anyone found violating the CoC or who is deemed to be a persistently unproductive participant and thus being disrespectful of other people's time"? To me that feels like saying "substitute with [CoC] or [not-malicious-but-wasting-everyone's-time], whichever fits the situation". And at that point I feel like we're treating CoC like a naughty word because we're not willing to say that someone who is wasting people's time isn't being disrespectful or inconsiderate even though they are.
But based on how others are stating their views, I'm seem to be in the minority on this one. I'm fine with that as I can view it personally as political wordsmithing. For me the key is that if I'm going to shoulder the burden of being a moderator I want to have the ability to keep discussions open, respectful, and considerate. If that means that someone gets a "CoC" label when they run afoul of those tenants by being mean while they get an "persistently unproductive" label when they run afoul of those labels in how they communicate then I can live with that.
P.S. I have removed the mention of the CoC from GitHub so that other than the thread discussing this situation there isn't any disconnected record of Wes violating the CoC.
On 3 April 2017 at 04:08, Brett Cannon brett@python.org wrote:
On Sun, 2 Apr 2017 at 04:34 Paul Moore p.f.moore@gmail.com wrote:
As a result, the public perception of a "code of conduct violation" is that someone has harassed, or otherwise made a community member uncomfortable, specifically because they don't conform to the stereotypical norm. That's not necessarily what any specific code of conduct might say, but it's how the public perceives such things (and high-profile blog entries that expose exclusive behaviour, and cite codes of conduct and how they help and where they fail to, simply reinforce that perception).
We may not like the fact that a simple term like "Code of Conduct" gets appropriated in the public perception in such a way, but denying the reality of it doesn't mean it doesn't happen.
But based on how others are stating their views, I'm seem to be in the minority on this one. I'm fine with that as I can view it personally as political wordsmithing. For me the key is that if I'm going to shoulder the burden of being a moderator I want to have the ability to keep discussions open, respectful, and considerate. If that means that someone gets a "CoC" label when they run afoul of those tenants by being mean while they get an "persistently unproductive" label when they run afoul of those labels in how they communicate then I can live with that.
I essentially agree with Brett here, but I also agree with MAL that at least for now we can keep this to a simpler two level system where:
- We write down explicit rules for encouraging productive,
collaborative discussions on PSF provided communication channels, together with the process that channel moderators are advised to follow when imposing temporary suspensions of posting privileges. We then explicitly adopt those rules for the core Python communication channels (python-dev, python-ideas, core-mentorship, the issue tracker and meta-tracker, the python org on GitHub) by updating the Developer Guide appropriately. The trigger for lifting suspensions imposed at this level can just be that: a) the minimum time period specified by the moderators has passed; b) the person suspended explicitly requests that the channel moderators restore their posting privileges.
Whether we call them "Rules for Active Participation" or something else, this step gives channel moderators the explicit authority to govern their channels according to their defined purpose, without having to rely on the Code of Conduct as the sole mechanism for ensuring that folks don't persist indefinitely in wasting other people's time.
- Anything that can't be handled through a temporary suspension of posting privileges gets escalated to the elected PSF Board. For example:
- cases where folks feel they have been suspended unfairly by moderators
- cases where moderators believe that a temporary suspension should be converted to a permanent ban
- cases where moderators believe that a ban from selected channels should be converted to a ban from all PSF provided communication channels
This step ensures that channel moderators have a place to appeal for assistance if behavioural management for particular individuals is acting as a persistent drain on *their* time and energy, as well as ensuring that there is a mechanism in place to request reviews of moderator actions that seem to be unreasonable.
The PSF Board has several desirable properties for this purpose:
- As the responsible legal entity, the PSF is already the de facto point of escalation for conduct related concerns on PSF provided communication channels
- Since the switch to an open membership model for the PSF, the Board is a genuinely representative body for the community at large
- As an elected body, the accountaibility mechanism for Board level decision making is built into the PSF By-laws
- The Board membership list at any given point in time is public information
- The Board is already set up to handle confidential discussion of sensitive matters
- The Board are in a good position to request PSF staff assistance in handling such matters when it seems appropriate to do so
If we started out by formalising that existing two level model of resource-specific moderators + the PSF (as represented by the Board), it would then be up to the *Board* to decide if it needed a formal process for delegating such discussions and decisions to a smaller group.
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hi,
First of all, sorry for bringing up an old thread. I know this is an uncomfortable topic, and I also wish that we can just avoid it, but ... I think we gotta do something about it.
I understand why Brett did what he did, and I support his decision.
I do agree with Raymond's point, that going forward, we should have a procedure in place, we all need to know what the rules are, and how to play by the rules.
Communities like Django Project and Write The Docs have clear enforcement manuals on what to do in case of CoC violation: https://www.djangoproject.com/conduct/enforcement-manual/ http://www.writethedocs.org/code-of-conduct-response/
Can we adopt something like that to our community, or do we have this already? If it requires involvement with the PSF board, who could bring this to their attention? (I'm new I don't know how these things work yet)
Brett's step-by-step guide above based on Raymond's proposal seems like a good start. Does that need to be approved by the board first? Or can we start by creating a PR to the devguide, and continue the discussion there?
I also want to discuss what the different actions to be taken in case someone is being negative. In one of the mailing lists, the violator gets a warning for their first offense. What if their first offense is severe enough, maybe a warning may not be suitable? Do we (core developers) want to decide all of these ourselves, or do we leave it PSF board to decide?
I just want to make sure that we are taking some actions going forward.
Mariatta Wijaya
On Sun, Apr 2, 2017 at 8:04 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On Sun, 2 Apr 2017 at 04:34 Paul Moore p.f.moore@gmail.com wrote:
As a result, the public perception of a "code of conduct violation" is that someone has harassed, or otherwise made a community member uncomfortable, specifically because they don't conform to the stereotypical norm. That's not necessarily what any specific code of conduct might say, but it's how the public perceives such things (and high-profile blog entries that expose exclusive behaviour, and cite codes of conduct and how they help and where they fail to, simply reinforce that perception).
We may not like the fact that a simple term like "Code of Conduct" gets appropriated in the public perception in such a way, but denying the reality of it doesn't mean it doesn't happen.
But based on how others are stating their views, I'm seem to be in the minority on this one. I'm fine with that as I can view it personally as political wordsmithing. For me the key is that if I'm going to shoulder
On 3 April 2017 at 04:08, Brett Cannon brett@python.org wrote: the
burden of being a moderator I want to have the ability to keep discussions open, respectful, and considerate. If that means that someone gets a "CoC" label when they run afoul of those tenants by being mean while they get an "persistently unproductive" label when they run afoul of those labels in how they communicate then I can live with that.
I essentially agree with Brett here, but I also agree with MAL that at least for now we can keep this to a simpler two level system where:
- We write down explicit rules for encouraging productive,
collaborative discussions on PSF provided communication channels, together with the process that channel moderators are advised to follow when imposing temporary suspensions of posting privileges. We then explicitly adopt those rules for the core Python communication channels (python-dev, python-ideas, core-mentorship, the issue tracker and meta-tracker, the python org on GitHub) by updating the Developer Guide appropriately. The trigger for lifting suspensions imposed at this level can just be that: a) the minimum time period specified by the moderators has passed; b) the person suspended explicitly requests that the channel moderators restore their posting privileges.
Whether we call them "Rules for Active Participation" or something else, this step gives channel moderators the explicit authority to govern their channels according to their defined purpose, without having to rely on the Code of Conduct as the sole mechanism for ensuring that folks don't persist indefinitely in wasting other people's time.
- Anything that can't be handled through a temporary suspension of posting privileges gets escalated to the elected PSF Board. For example:
- cases where folks feel they have been suspended unfairly by moderators
- cases where moderators believe that a temporary suspension should be converted to a permanent ban
- cases where moderators believe that a ban from selected channels should be converted to a ban from all PSF provided communication channels
This step ensures that channel moderators have a place to appeal for assistance if behavioural management for particular individuals is acting as a persistent drain on *their* time and energy, as well as ensuring that there is a mechanism in place to request reviews of moderator actions that seem to be unreasonable.
The PSF Board has several desirable properties for this purpose:
- As the responsible legal entity, the PSF is already the de facto point of escalation for conduct related concerns on PSF provided communication channels
- Since the switch to an open membership model for the PSF, the Board is a genuinely representative body for the community at large
- As an elected body, the accountaibility mechanism for Board level decision making is built into the PSF By-laws
- The Board membership list at any given point in time is public information
- The Board is already set up to handle confidential discussion of sensitive matters
- The Board are in a good position to request PSF staff assistance in handling such matters when it seems appropriate to do so
If we started out by formalising that existing two level model of resource-specific moderators + the PSF (as represented by the Board), it would then be up to the *Board* to decide if it needed a formal process for delegating such discussions and decisions to a smaller group.
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Wed, May 3, 2017 at 3:28 PM, Mariatta Wijaya mariatta.wijaya@gmail.com wrote:
Hi,
First of all, sorry for bringing up an old thread. I know this is an uncomfortable topic, and I also wish that we can just avoid it, but ... I think we gotta do something about it.
I understand why Brett did what he did, and I support his decision.
I do agree with Raymond's point, that going forward, we should have a procedure in place, we all need to know what the rules are, and how to play by the rules.
Communities like Django Project and Write The Docs have clear enforcement manuals on what to do in case of CoC violation: https://www.djangoproject.com/conduct/enforcement-manual/ http://www.writethedocs.org/code-of-conduct-response/
Can we adopt something like that to our community, or do we have this already? If it requires involvement with the PSF board, who could bring this to their attention? (I'm new I don't know how these things work yet)
It should not require PSF involvement. Enforcing violation of the CoC is up whichever group applied the CoC and how it factors into the medium it's being applied to, so I think we just do that right here. That's partly why the CoC itself says nothing about consequences, as the myriad of environments this could be (and is) applied to vary, so there is no one-size-fits-all answer to what happens when it's violated.
Since this is a matter outside the realm of committers, the PSF board will have to ultimately decide on any actions taken.
The committers can report issues to the board and provide information useful for their decisions, the bad actor also has to be given a chance to respond to allegations and be heard. Then the board can decide what to do.
The two manuals should not be used or proposed as a guideline for CoC handling, since they completely ignore the basic rights of the alleged bad actors to a fair process.
When I was a board member, we had already discussed this at the board level and used to deal with such issues on a case by case basis, which always included trying to contact the persons in questions either directly or via a mediator.
This has worked well and I don't see a good reason to suggest using a less open and fair approach.
Cheers,
Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 03 2017)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On 03.05.2017 21:28, Mariatta Wijaya wrote:
Hi,
First of all, sorry for bringing up an old thread. I know this is an uncomfortable topic, and I also wish that we can just avoid it, but ... I think we gotta do something about it.
I understand why Brett did what he did, and I support his decision.
I do agree with Raymond's point, that going forward, we should have a procedure in place, we all need to know what the rules are, and how to play by the rules.
Communities like Django Project and Write The Docs have clear enforcement manuals on what to do in case of CoC violation: https://www.djangoproject.com/conduct/enforcement-manual/ http://www.writethedocs.org/code-of-conduct-response/
Can we adopt something like that to our community, or do we have this already? If it requires involvement with the PSF board, who could bring this to their attention? (I'm new I don't know how these things work yet)
Brett's step-by-step guide above based on Raymond's proposal seems like a good start. Does that need to be approved by the board first? Or can we start by creating a PR to the devguide, and continue the discussion there?
I also want to discuss what the different actions to be taken in case someone is being negative. In one of the mailing lists, the violator gets a warning for their first offense. What if their first offense is severe enough, maybe a warning may not be suitable? Do we (core developers) want to decide all of these ourselves, or do we leave it PSF board to decide?
I just want to make sure that we are taking some actions going forward.
Mariatta Wijaya
On Sun, Apr 2, 2017 at 8:04 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On Sun, 2 Apr 2017 at 04:34 Paul Moore p.f.moore@gmail.com wrote:
As a result, the public perception of a "code of conduct violation" is that someone has harassed, or otherwise made a community member uncomfortable, specifically because they don't conform to the stereotypical norm. That's not necessarily what any specific code of conduct might say, but it's how the public perceives such things (and high-profile blog entries that expose exclusive behaviour, and cite codes of conduct and how they help and where they fail to, simply reinforce that perception).
We may not like the fact that a simple term like "Code of Conduct" gets appropriated in the public perception in such a way, but denying the reality of it doesn't mean it doesn't happen.
But based on how others are stating their views, I'm seem to be in the minority on this one. I'm fine with that as I can view it personally as political wordsmithing. For me the key is that if I'm going to shoulder
On 3 April 2017 at 04:08, Brett Cannon brett@python.org wrote: the
burden of being a moderator I want to have the ability to keep discussions open, respectful, and considerate. If that means that someone gets a "CoC" label when they run afoul of those tenants by being mean while they get an "persistently unproductive" label when they run afoul of those labels in how they communicate then I can live with that.
I essentially agree with Brett here, but I also agree with MAL that at least for now we can keep this to a simpler two level system where:
- We write down explicit rules for encouraging productive,
collaborative discussions on PSF provided communication channels, together with the process that channel moderators are advised to follow when imposing temporary suspensions of posting privileges. We then explicitly adopt those rules for the core Python communication channels (python-dev, python-ideas, core-mentorship, the issue tracker and meta-tracker, the python org on GitHub) by updating the Developer Guide appropriately. The trigger for lifting suspensions imposed at this level can just be that: a) the minimum time period specified by the moderators has passed; b) the person suspended explicitly requests that the channel moderators restore their posting privileges.
Whether we call them "Rules for Active Participation" or something else, this step gives channel moderators the explicit authority to govern their channels according to their defined purpose, without having to rely on the Code of Conduct as the sole mechanism for ensuring that folks don't persist indefinitely in wasting other people's time.
- Anything that can't be handled through a temporary suspension of posting privileges gets escalated to the elected PSF Board. For example:
- cases where folks feel they have been suspended unfairly by moderators
- cases where moderators believe that a temporary suspension should be converted to a permanent ban
- cases where moderators believe that a ban from selected channels should be converted to a ban from all PSF provided communication channels
This step ensures that channel moderators have a place to appeal for assistance if behavioural management for particular individuals is acting as a persistent drain on *their* time and energy, as well as ensuring that there is a mechanism in place to request reviews of moderator actions that seem to be unreasonable.
The PSF Board has several desirable properties for this purpose:
- As the responsible legal entity, the PSF is already the de facto point of escalation for conduct related concerns on PSF provided communication channels
- Since the switch to an open membership model for the PSF, the Board is a genuinely representative body for the community at large
- As an elected body, the accountaibility mechanism for Board level decision making is built into the PSF By-laws
- The Board membership list at any given point in time is public information
- The Board is already set up to handle confidential discussion of sensitive matters
- The Board are in a good position to request PSF staff assistance in handling such matters when it seems appropriate to do so
If we started out by formalising that existing two level model of resource-specific moderators + the PSF (as represented by the Board), it would then be up to the *Board* to decide if it needed a formal process for delegating such discussions and decisions to a smaller group.
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Two ex-board members disagree. I have to side with Brian; the PSF board should have minimal say in how the developers develop.
Note, I'm fine with the board being the arbiter when someone disagrees with their ban though -- there's got to be a "higher authority" for appeals. But I don't agree that the board should be the decider on the initial ban. Maybe for additional oversight bans should be required to be reported to the board in a timely fashion. (Ain't I the lawyer. ;-)
On Wed, May 3, 2017 at 12:48 PM, M.-A. Lemburg mal@egenix.com wrote:
Since this is a matter outside the realm of committers, the PSF board will have to ultimately decide on any actions taken.
The committers can report issues to the board and provide information useful for their decisions, the bad actor also has to be given a chance to respond to allegations and be heard. Then the board can decide what to do.
The two manuals should not be used or proposed as a guideline for CoC handling, since they completely ignore the basic rights of the alleged bad actors to a fair process.
When I was a board member, we had already discussed this at the board level and used to deal with such issues on a case by case basis, which always included trying to contact the persons in questions either directly or via a mediator.
This has worked well and I don't see a good reason to suggest using a less open and fair approach.
Cheers,
Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 03 2017)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On 03.05.2017 21:28, Mariatta Wijaya wrote:
Hi,
First of all, sorry for bringing up an old thread. I know this is an uncomfortable topic, and I also wish that we can just avoid it, but ... I think we gotta do something about it.
I understand why Brett did what he did, and I support his decision.
I do agree with Raymond's point, that going forward, we should have a procedure in place, we all need to know what the rules are, and how to play by the rules.
Communities like Django Project and Write The Docs have clear enforcement manuals on what to do in case of CoC violation: https://www.djangoproject.com/conduct/enforcement-manual/ http://www.writethedocs.org/code-of-conduct-response/
Can we adopt something like that to our community, or do we have this already? If it requires involvement with the PSF board, who could bring this to their attention? (I'm new I don't know how these things work yet)
Brett's step-by-step guide above based on Raymond's proposal seems like a good start. Does that need to be approved by the board first? Or can we start by creating a PR to the devguide, and continue the discussion there?
I also want to discuss what the different actions to be taken in case someone is being negative. In one of the mailing lists, the violator gets a warning for their first offense. What if their first offense is severe enough, maybe a warning may not be suitable? Do we (core developers) want to decide all of these ourselves, or do we leave it PSF board to decide?
I just want to make sure that we are taking some actions going forward.
Mariatta Wijaya
On Sun, Apr 2, 2017 at 8:04 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On Sun, 2 Apr 2017 at 04:34 Paul Moore p.f.moore@gmail.com wrote:
As a result, the public perception of a "code of conduct violation" is that someone has harassed, or otherwise made a community member uncomfortable, specifically because they don't conform to the stereotypical norm. That's not necessarily what any specific code of conduct might say, but it's how the public perceives such things (and high-profile blog entries that expose exclusive behaviour, and cite codes of conduct and how they help and where they fail to, simply reinforce that perception).
We may not like the fact that a simple term like "Code of Conduct" gets appropriated in the public perception in such a way, but denying the reality of it doesn't mean it doesn't happen.
But based on how others are stating their views, I'm seem to be in the minority on this one. I'm fine with that as I can view it personally as political wordsmithing. For me the key is that if I'm going to shoulder
On 3 April 2017 at 04:08, Brett Cannon brett@python.org wrote: the
burden of being a moderator I want to have the ability to keep discussions open, respectful, and considerate. If that means that someone gets a "CoC" label when they run afoul of those tenants by being mean while they get an "persistently unproductive" label when they run afoul of those labels in how they communicate then I can live with that.
I essentially agree with Brett here, but I also agree with MAL that at least for now we can keep this to a simpler two level system where:
- We write down explicit rules for encouraging productive,
collaborative discussions on PSF provided communication channels, together with the process that channel moderators are advised to follow when imposing temporary suspensions of posting privileges. We then explicitly adopt those rules for the core Python communication channels (python-dev, python-ideas, core-mentorship, the issue tracker and meta-tracker, the python org on GitHub) by updating the Developer Guide appropriately. The trigger for lifting suspensions imposed at this level can just be that: a) the minimum time period specified by the moderators has passed; b) the person suspended explicitly requests that the channel moderators restore their posting privileges.
Whether we call them "Rules for Active Participation" or something else, this step gives channel moderators the explicit authority to govern their channels according to their defined purpose, without having to rely on the Code of Conduct as the sole mechanism for ensuring that folks don't persist indefinitely in wasting other people's time.
- Anything that can't be handled through a temporary suspension of posting privileges gets escalated to the elected PSF Board. For example:
- cases where folks feel they have been suspended unfairly by moderators
- cases where moderators believe that a temporary suspension should be converted to a permanent ban
- cases where moderators believe that a ban from selected channels should be converted to a ban from all PSF provided communication channels
This step ensures that channel moderators have a place to appeal for assistance if behavioural management for particular individuals is acting as a persistent drain on *their* time and energy, as well as ensuring that there is a mechanism in place to request reviews of moderator actions that seem to be unreasonable.
The PSF Board has several desirable properties for this purpose:
- As the responsible legal entity, the PSF is already the de facto point of escalation for conduct related concerns on PSF provided communication channels
- Since the switch to an open membership model for the PSF, the Board is a genuinely representative body for the community at large
- As an elected body, the accountaibility mechanism for Board level decision making is built into the PSF By-laws
- The Board membership list at any given point in time is public information
- The Board is already set up to handle confidential discussion of sensitive matters
- The Board are in a good position to request PSF staff assistance in handling such matters when it seems appropriate to do so
If we started out by formalising that existing two level model of resource-specific moderators + the PSF (as represented by the Board), it would then be up to the *Board* to decide if it needed a formal process for delegating such discussions and decisions to a smaller group.
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
On 4 May 2017 at 06:10, Guido van Rossum guido@python.org wrote:
Two ex-board members disagree. I have to side with Brian; the PSF board should have minimal say in how the developers develop.
Note, I'm fine with the board being the arbiter when someone disagrees with their ban though -- there's got to be a "higher authority" for appeals. But I don't agree that the board should be the decider on the initial ban.
I think initial temporary suspensions should definitely be handled without involving the Board (just as they are for any other PSF provided channel).
I also think there are two cases that can definitely only be handled at the board level:
- folks that feel they've been treated unfairly by the core development team appealing to the Board for reconsideration
- the core development team recommending that a ban from our channels (python-dev, python-ideas, core-workflow, bugs.python.org, GitHub python org) be extended to other PSF provided channels
I'd previously said that I thought conversion of temporary suspensions to permanent bans should also go to the Board, but I now think it makes more sense to handle that as:
- the Board gets notified if a temporary suspension is now considered a permanent ban
- they only need to get further involved if the ban is appealed
Cheers, Nick.
P.S. Don't forget that the specific context here is *public* behaviour that is the domain of channel moderators, rather than confidentially reported Code of Conduct concerns. Handling of the latter will remain with the PSF Board or their appointed representatives, independently of how we handle moderation of the development channels.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Thanks everyone for the input.
It is still unclear to me how one can report when someone is being rude on GitHub. In the mailing lists we can email the administrators. But what about on GitHub? Do I write to python-committers? What if it was a core developer who was being rude, where can a non core-dev contributor report such behavior?
Mariatta Wijaya
On Thu, May 4, 2017 at 6:53 AM, Nick Coghlan ncoghlan@gmail.com wrote:
On 4 May 2017 at 06:10, Guido van Rossum guido@python.org wrote:
Two ex-board members disagree. I have to side with Brian; the PSF board should have minimal say in how the developers develop.
Note, I'm fine with the board being the arbiter when someone disagrees with their ban though -- there's got to be a "higher authority" for appeals. But I don't agree that the board should be the decider on the initial ban.
I think initial temporary suspensions should definitely be handled without involving the Board (just as they are for any other PSF provided channel).
I also think there are two cases that can definitely only be handled at the board level:
- folks that feel they've been treated unfairly by the core development team appealing to the Board for reconsideration
- the core development team recommending that a ban from our channels (python-dev, python-ideas, core-workflow, bugs.python.org, GitHub python org) be extended to other PSF provided channels
I'd previously said that I thought conversion of temporary suspensions to permanent bans should also go to the Board, but I now think it makes more sense to handle that as:
- the Board gets notified if a temporary suspension is now considered a permanent ban
- they only need to get further involved if the ban is appealed
Cheers, Nick.
P.S. Don't forget that the specific context here is *public* behaviour that is the domain of channel moderators, rather than confidentially reported Code of Conduct concerns. Handling of the latter will remain with the PSF Board or their appointed representatives, independently of how we handle moderation of the development channels.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Maybe there should be a published list of moderators (not a mailing list, just a list of people to mail!) where you can send such reports. If a moderator is being rude it's probably time to escalate to the PSF.
Thanks for pushing for a definite process on this issue!
On Fri, May 5, 2017 at 11:44 AM, Mariatta Wijaya mariatta.wijaya@gmail.com wrote:
Thanks everyone for the input.
It is still unclear to me how one can report when someone is being rude on GitHub. In the mailing lists we can email the administrators. But what about on GitHub? Do I write to python-committers? What if it was a core developer who was being rude, where can a non core-dev contributor report such behavior?
Mariatta Wijaya
On Thu, May 4, 2017 at 6:53 AM, Nick Coghlan ncoghlan@gmail.com wrote:
On 4 May 2017 at 06:10, Guido van Rossum guido@python.org wrote:
Two ex-board members disagree. I have to side with Brian; the PSF board should have minimal say in how the developers develop.
Note, I'm fine with the board being the arbiter when someone disagrees with their ban though -- there's got to be a "higher authority" for appeals. But I don't agree that the board should be the decider on the initial ban.
I think initial temporary suspensions should definitely be handled without involving the Board (just as they are for any other PSF provided channel).
I also think there are two cases that can definitely only be handled at the board level:
- folks that feel they've been treated unfairly by the core development team appealing to the Board for reconsideration
- the core development team recommending that a ban from our channels (python-dev, python-ideas, core-workflow, bugs.python.org, GitHub python org) be extended to other PSF provided channels
I'd previously said that I thought conversion of temporary suspensions to permanent bans should also go to the Board, but I now think it makes more sense to handle that as:
- the Board gets notified if a temporary suspension is now considered a permanent ban
- they only need to get further involved if the ban is appealed
Cheers, Nick.
P.S. Don't forget that the specific context here is *public* behaviour that is the domain of channel moderators, rather than confidentially reported Code of Conduct concerns. Handling of the latter will remain with the PSF Board or their appointed representatives, independently of how we handle moderation of the development channels.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-- --Guido van Rossum (python.org/~guido)
Thanks, Raymond, this reads like a good proposal, but I'd like to suggest that the three people in question are only intended to discuss whether a CoC event has taken place or not and what the person has to say about this.
They should then write up a summary to present to the PSF Board which then decides. We have already had precedents for this and it worked well.
No single moderator of a PSF resource should be allowed to impose a ban on anyone. I also don't think that what Wes has done is serious enough to be considered a CoC violation or that a ban was the right action to take.
What I miss in the proposal is more emphasis on getting feedback from the person in question (I often see CoC rule sets miss out on this - even though it's one of the most basic human rights principles: the right to a fair trial) and trying to change behavior before CoC actions such as bans have to be triggered.
In most cases, it's possible to find a way forward without any actions and that's what we should strive for as a community.
Thanks,
Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 31 2017)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On 02.04.2017 01:07, Raymond Hettinger wrote:
I would like to make a procedural proposal based on the ideas emerging from the other python-committers discussion regarding the two month suspension of Github project access for a developer who was posting non-productively.
It seems that there is general agreement to differentiate commonplace list moderation actions from CoC actions which are more of a nuclear option to be reserved for egregious cases of harassment and abuse.
Also, there is general agreement not to concentrate that power in the hands of a single person and that we should have some principles and procedures in place.
I propose that when someone thinks there is a problem serious enough to warrant a Code-of-Conduct action, that it get referred to a group of three people to make the decision. Two of those three people should be long-term, senior, and respected core devs who have good knowledge of the community (Brett Cannon, Nick Coghlan, Antoine Pitrou, et al). The third person should be someone who is also well-respected but more independent and who has more experience in sociology and community management issues (Alex Gaynor or Carol Willing come to mind).
To prevent endless bickering and sharing of sensitive details, the group's decision should be considered settled business which can only be overridden either by an appeal to the PSF board or by the BDFL. When possible, the affected person should be contacted and given an opportunity to defend themselves. The decision shall be announced on python-committers with an overall rationale but without personal details.
The group shall consider the needs of the community first and foremost, and secondarily shall prioritize being as respectful as possible to all parties, and thirdly shall do whatever they can to mitigate the harm to the violator. The actions shall be taken with an intent to protect the vibrancy of the Python community rather than with an intent to punish, humiliate, or discredit the affected person. When possible, some path to redemption or forgiveness shall be offered.
Respectfully submitted,
Raymond Hettinger
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
participants (10)
-
Alexander Belopolsky -
Brett Cannon -
Brian Curtin -
Guido van Rossum -
M.-A. Lemburg -
Mariatta Wijaya -
Nick Coghlan -
Paul Moore -
Raymond Hettinger -
Steven D'Aprano