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

Marc-Andre Lemburg

Professional Python Services directly from the Experts (#1, May 03 2017)
>>> Python Projects, Coaching and Consulting ...
>>> Python Database Interfaces ... 
>>> Plone/Zope Database Interfaces ... 

::: We implement business ideas - efficiently in both time and costs ::: 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

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:
> 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 <> wrote:
>> On 3 April 2017 at 04:08, Brett Cannon <> wrote:
>>> On Sun, 2 Apr 2017 at 04:34 Paul Moore <> 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
>> 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:
>> 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
>> group.
>> Regards,
>> Nick.
>> --
>> Nick Coghlan   |   |   Brisbane, Australia
>> _______________________________________________
>> python-committers mailing list
>> Code of Conduct:
> _______________________________________________
> python-committers mailing list
> Code of Conduct:

python-committers mailing list
Code of Conduct:

--Guido van Rossum (