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/