Move to the PSF Code of Conduct?

After what happened to pytest the other day (for those that don’t know, 3 maintainers quit over a single bad actor for which it seems their CoC committee didn’t take action against beyond a single warning), I decided to check what the PyPA had for a CoC. Best I could find is but no direct for file for either pip or ‘packaging’ (I didn’t look any deeper).

Would people be willing to shift to the PSF Code of Conduct and mandating all projects adopt it visibly? I assume the pypa organization on GitHub is not under the PSF (if it is then we are technically out of compliance since the PSF requires its CoC be used). It would also provide clear reporting and enforcement procedures.

1 Like

Currently, one of the requirement for projects under the PyPA umbrella (whatever that’s worth) is “Adopt the PyPA CoC”. I think it’s very reasonable for the PyPA CoC to be replaced with the PSF CoC.

FWIW, in the world that PEP 609 describes, a lot of Python packaging stuff would be under the SC’s mandate, so I imagine we might as well adopt the PSF CoC.

no direct for file for either pip or ‘packaging’

It’s mentioned in the README (+ for pip).

I’m OK with this, but to be clear, does that mean that authority for enforcing the CoC would go to the PSF’s CoC group, rather than being handled by the projects themselves?

As far as virtualenv goes I’d be happy with PSF handling CoC for the PyPa (including pip).

I’d be in favor of moving to the PSF CoC, including the PSF CoC handling procedure. The PSF CoC is better than the current PyPA one, and the PyPA currently doesn’t really have any enforcement procedure at all. (Doing enforcement well is really hard, but without an enforcement policy a CoC is largely useless.)

1 Like

The pytest resignations were, apparently, due to failure to enforce the
CoC, not due to failures of the CoC.

If that is the case, why is changing the CoC necessary and what will it

That’s great! GitHub has extra integration/notification if there is a file, though, so if we do this it might be good to put a file there, especially if it specifies who to contact.

It’s up to the project. The reporting guidelines say to report to the projec if possible and falls back to the Conduct WG if there isn’t any place to report issues.

As for enforcing, the enforcement guide says the Conduct WG makes a recommendation to the admins/moderators that the incident falls under and they either go with it or do their own thing, although the outcome can get reported up to the PSF board if things are not being handled well or ignored.

To make this more concrete, for python-ideas and here on, when an issue has come up I have reported the incidents to the Conduct WG so it gets reported (having a record that spans various corners of our community is important so people don’t spread their bad behaviour thinly enough across the whole community that no one picks up on the pattern). After that the admins and I typically have a suggestion of what we think is an appropriate response and they act as a neutral third-party to make sure the response is within reason (e.g. they have suggested scaling back a response once).

Because if you look at the PyPA CoC it’s rather weak. For reporting it says to:

… [open] an issue or contacting one or more of the project maintainers.

Doing that publicly is not always an option, so who is a “project maintainer” to contact? It’s rather open-ended and ill-defined for a group of self-organized projects that don’t publish their org chart. :wink: But seriously, I have no clue who I would report an issue within the PyPA organization to and I’m considered a member of the org.

As for enforcement, the PyPA CoC is also a bit weak IMO:

… remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct.

What about bans, temporary or permanent? Following this CoC suggests that isn’t possible. That would suggest a bad actor can do what they want and just keep the project administrators busy by constantly being rude with no fear of being banned to stop their negative interference in the project.

Lastly, there’s no appeal process. With the PSF CoC you can go all the way up to the PSF board to settle an issue if you choose to dispute the result. Under the PyPA CoC there isn’t a well-defined final arbiter and so you’re stuck with whatever the undefined “administrators” say the result is. At least with the PSF board you have an elected group of people to appeal to if necessary.

Now full disclosure, I’m a founding member of the Conduct WG and helped draft the CoC, reporting, and enforcement guides.

I will also say that I have not explicitly discussed this idea with the Conduct WG of taking on the PyPA, but I have no reason to expect them to say “no”.


Thanks for the explanation Brett.


I agree but this would ideally require the acceptance of all PyPA (~20) projects.

As a pip maintainer, I’d gladly shift to the PSF CoC :+1:

1 Like

As a side-note, the tone was always rough in the Pytest project. I’m not sure we can blame the CoC for this. The last of the three leaving (according to the mailing list) was arguably the worst communicator of all the maintainers. Only the first seems to have a valid reason for leaving, the others’ announcements I find a bit hypocritical. Personally, I found the one person now seemingly being blamed for all the rage the most supportive in various projects. Just saying…

1 Like

FWIW, we decided to go for PSF’s CoC and enforcement procedures in our last conference (PyConDE/PyData Berlin) and it proved to be a really nice one. At least according to our understanding, we didn’t lose any control and we had to handle all the cases (of which we had ~3 IIRC), and the procedures made it really easy to follow and handle the cases. That said, we didn’t have a CoC case against any of the main organizers, which would be equivalent to having a case against a main contributor in the case of PyTest, but I’d say had it happened, it would still be much easier to follow PSF’s procedures than not having one to follow.

Re: GitHub integration, it’s possible to set a default file for all repos under an organisation -

PyPA might also want to do this for and

1 Like

i believe when I added the CoC to all of the PyPA projects, didn’t exist as a thing in GitHub, so I opt’d to put it in the most visible places we had at that time. No problem for me if we add this file.

The few times it’s come up, I think the answer has been me but I think that was mostly people just guessing based on people knowing my involvement.

CoCs are not legal documents, enforcement actions not explicitly enumerated can be applied. If someone was violating-enough to lead to that, the lack of explicitly saying the words “ban” in the CoC is not going to stop that from occurring.

The PyPA isn’t “under” the PSF… are they willing to add potentially arbitrating any hypothetical appeals for a related, but not owned by them, set of projects? I assume so, but worth explicitly asking it.

I actually had not noticed that the PSF had even updated their CoC, so I’m not sure when that happened but it’s nice to see that it’s actually a pretty decent one now. If this had existed when I introduced the CoC to PyPA projects I likely would have just used it instead of cribbing from the contributor covenant.

As an aside, PyPI currently says it falls under the PyPA CoC (rationale), and from reading this announcement it sounds like for the PyPI instance itself, that needs to change now to the PSF CoC, and for Warehouse it would then go back to the PyPA CoC… which making this change would align those two edge cases back under a single CoC again.

1 Like

That would be part of the deal. Basically when it comes to CoC the projects would be acting as if they were any other PSF project.

@brettcannon How can one initiate this discussion with the Conduct WG? It would be useful to know what they think, before doing a push to verify that all PyPA projects are indeed OK with this change.

I was planning to start it officially on Monday to give people the weekend to comment.

Already started the conversation unofficially the other day. The WG seems amenable with some simple requirements (e.g. specifying who the contact person is and listing that in a file). But the key thing is I had to start the conversation with someone first. :slight_smile:


Quick update: it’s looking like the Conduct WG will be up for this idea. We are in the midst of setting up regular meetings and at the first one we are going to discuss this topic. I’ll report back when again when there’s more concrete information.


Thanks @brettcannon. For what it’s worth, I am, like (I think) approximately everyone in this thread, in favor of having the PyPA move to the PSF Code of Conduct, including the PSF CoC handling procedure. And thank you for moving to get this addressed.

If you would like for anyone from the PyPA to guest-star in part of a Conduct WG meeting, just to talk a bit about logistics, please do speak up here and let us know! In a pinch I could be that person.

The Conduct WG had a chat and this is what we think we would ask of the PyPA and what that would then mean the PyPA would get:

  1. Have a file (repo or org).
  2. MD file links to
  3. MD file lists who the admins/moderators are to contact in case of an incident.
  4. MD file mentions that in cases which involve the above admins/moderators, feel free to email
  5. Admins/moderators are expected to report up to the Conduct WG any incidents for recording purposes.
  6. We promise to help admins/moderators with any questions/needs they may have.
  7. The PyPA also gets to directly use the PSF CoC and any ancillary things (i.e. reporting guidelines and enforcement guide).

Does this all seem reasonable to folks?


Sounds good to me.