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:

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 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:

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

2. Anything that can't be handled through a temporary suspension of
posting privileges gets escalated to the elected PSF Board. For

- 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

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:

1. As the responsible legal entity, the PSF is already the de facto
point of escalation for conduct related concerns on PSF provided
communication channels
2. Since the switch to an open membership model for the PSF, the Board
is a genuinely representative body for the community at large
3. As an elected body, the accountaibility mechanism for Board level
decision making is built into the PSF By-laws
4. The Board membership list at any given point in time is public information
5. The Board is already set up to handle confidential discussion of
sensitive matters
6. 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


Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
python-committers mailing list
Code of Conduct: https://www.python.org/psf/codeofconduct/