Move to the PSF Code of Conduct?

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 CODE_OF_CONDUCT.md file). But the key thing is I had to start the conversation with someone first. :slight_smile:

3 Likes

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.

2 Likes

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 CODE_OF_CONDUCT.md file (repo or org).
  2. MD file links to https://www.python.org/psf/conduct/.
  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 conduct-wg@python.org.
  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?

4 Likes

Sounds good to me.

Sounds good to me.

If @brettcannon, @pf_moore, @pradyunsg, @dustin, @dstufft, or other experienced folks have a suggestion for “here’s how we will verify enough consensus to finalize this decision” using this Discourse thread, I’m happy to hear it. But I suggest we instead get PEP 609 in place (PEP 609: PyPA Governance), and then use its committer vote mechanism to get a clear ratification of this change.

Best you will probably get is no one has complained. :sweat_smile: Otherwise more hearts and positive replies than negative. It’s a a drawback from the lack of official project structure compared to e.g. python-dev where the steering council made the CoC decision. But as you said, PEP 609 would help with this.

Sounds good to me.

I don’t have a better way to get consensus unless we want to informally do what PEP 609 suggests as the formal process, but I’m not sure that’s necessary here. I like @brettcannon’s suggestion.

+1 from me to move this in.

PEP 609 now says that PyPA projects will follow the PSF CoC (and also brings the PyPA under the Steering Council’s mandate).

If/when that PEP is accepted, we should move forward on moving PyPA over to the PSF CoC, as laid out by @brettcannon [earlier in this thread] (Move to the PSF Code of Conduct?).

If that PEP gets rejected, I suggest we still move forward with this, since under our “not actually formalized” process, no one has opposed doing this so we can move forward and do this. :slight_smile:


If anyone has concerns / issues with the PyPA adopting the PSF CoC, now would be a really good time to voice them.

Would people be willing to shift to the PSF Code of Conduct and mandating all projects adopt it visibly?

What does that mean exactly? That all PYPA projects will inherently adopt the Python CoC? Or that all projects on PYPI will? I don’t want my projects to be (directly or indirectly) associated with any CoC.

I’m asking because pytest doesn’t seem to be part of the PYPA organization on GitHub, so I’m not sure I understand the extension of this decision and what packages are going to be affected.

This thread is specifically about PyPA projects. No other projects on PyPI are implied or included.

4 Likes

With PEP 609 now accepted, I created https://github.com/pypa/.github and https://github.com/pypa/.github/pull/1 to adopt the PSF CoC across all PyPA projects.

In the process of doing this, I was hesitant to add the following:

  1. I’m concerned about having to maintain an up-to-date list of the PyPA admin/moderators (and having to expose their personal contact information)

  2. I’m concerned about deviating from the existing PSF CoC process by adding an intermediate step here, especially if we’re just going to be reporting all incidents up to the Conduct-WG anyways.

I think I’d prefer if we just simplify things by following the same incident reporting procedure that the PSF CoC outlines instead, and the Conduct-WG can route any PyPA-related incidents to us as necessary.

1 Like

Can we expose only their github user? :thinking: That should be public already together with their e-mail used for their commits.

I think the suggestion was to not just expose who would be handling CoC reports (which the GitHub user would be fine for) but also a point of contact, which would require email, or some mailing list that has all the committers on it, which is yet another thing to keep up to date.

Also, not all users have a “valid” email associated with their commits. For example, all my commits have From: Dustin Ingram <di@users.noreply.github.com>, which is not an address that receives mail.

It doesn’t have to be unique per-repository. It can be a handful of people that are trusted to make reasonable CoC decisions and are willing to do the work.

Another option is to set up a mailing list at mail.python.org whose archives are private and only those people who are CoC moderators can subscribe to. Then all emails to the list will end up in the moderation queue and you can let them in as appropriate.

Not doing this is the actual deviation, not what the Conduct WG asked the PyPA do (so to be clear, the Conduct WG explicitly asked for that structure, not me personally).

For mailing lists and such, the Conduct WG acts as a central entity to record incidents and to provide guidance. But otherwise they are not expected to be front-line for this sort of thing (otherwise they would potentially get overwhelmed as the WG isn’t that big). So wanting to cut us out and hoist it all to the Conduct WG is not standard and would probably lead the Conduct WG not on-boarding other projects as it just won’t scale for the WG.

Got it, thanks. Sounds like we need to identify who is willing to be a part of this group, and set up a mailing list / alias as appropriate, before we can merge that.

Any volunteers?

1 Like

I’m not the greatest at staying on top of email anymore, but if we need people I’m happy to try and stay on top of this list as one of the people. But if we get enough other volunteers, I’m happy to also not be one of the people.

I’m up for it.

I think it’d probably be wise to have at least one person from each of the more-active projects.

(apologies if I’m missing anyone)