Move to the PSF Code of Conduct?

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)

I’d rather not be a CoC moderator.

I’m unable to be a primary responder for such a list, but I’m willing and able to provide robust support on explicit request incidentally (a couple of times per year).

I’m gonna say that @dstufft covers us, since he’s a pip maintainer too. :slight_smile:

Ditto for me.

To clarify my comment, by the way, I’m not entirely sure what’s being asked of people here. I took it as meaning “being asked to make decisions on allegations of CoC violations” - specifically deciding whether there actually was a violation, and secondarily deciding what the response should be.

Given that, I’m not quite sure what “providing support” as @jaraco describes it would mean. Maybe I could do that, it depends what it is. I can certainly imagine the main responders on the list feeling the need for support, but I would expect that to come from the Conduct WG. IMO confidentiality is important in these types of situation, and having too large a group would seem to go counter to that. We already have 5 people if you assume one per project mentioned.

Having said all this, I really hope that this is a very infrequently needed responsibility. If we’re dealing with any sorts of CoC violation reports more than once or twice a year, I think we’re probably doing something wrong…

To be more clear, what’s being asked is:

  • have yourself added to a conduct@pypa.io email address (or something similar)
  • have your name publicly listed as a responder for this email address
  • help triage emails received to this address when they arrive
  • help determine whether there has been a violation of the PSF CoC & the response
  • help summarize/report incidents to the Conduct WG for recording purposes

I would imagine that a) we shouldn’t be receiving a high volume of mail to this address, and b) we would most need your assistance when it relates to a project you maintain.