Implementing PEP 609: PyPA Governance

Sure, something like

The existing link is to, which says:

All PyPA contributors and maintainers are expected to follow the PSF Code of Conduct. Please see PyPA-specific details.

(PyPA previously had its own code of conduct separate from PSF’s; PEP 609 switched PyPA to PSF’s Code of Conduct.)

Is that existing link okay, or would it better going direct to or elsewhere?

On that PR, @pradyunsg suggested linking directly to because it skips needing to click through an extra link to get to the relevant reporting details, so I’ll go for that one. :+1:

Edit: There we go! That should be the lot:

1 Like

Hurray! Thanks a lot for doing this @hugovk! ^.^

1 Like

Because Discourse is nice, I’ve added a checklist to the first-post here, and checked off the first box. :slight_smile:

1 Like

OK, I’ve found a way to get every user with the commit bit in the GitHub org. I don’t have everyone’s email address, however. I’ve added all the users I do have emails for, but I’m missing the following:

dholth           pip scripttest packaging-problems get-pip virtualenv pip-test-package browntruck pypa-docs-theme sampleproject get-virtualenv wheel
dwighthubbard    bandersnatch
erinxocon        pipenv
idlesign         packaging-problems setuptools
Ivoz             pip scripttest packaging-problems get-pip virtualenv pip-test-package browntruck pypa-docs-theme sampleproject get-virtualenv
JustinCappos     packaging-problems interoperability-peps
ken-reitz        pipenv pipfile
matthew-brett    wheel-builders auditwheel manylinux python-manylinux-demo
mayeut           wheel-builders auditwheel manylinux python-manylinux-demo
natefoo          wheel-builders auditwheel manylinux python-manylinux-demo
pjenvey          packaging-problems get-virtualenv virtualenv
r1chardj0n3s     packaging-problems sample-namespace-packages pypa-docs-theme interoperability-peps
rmcgibbo         wheel-builders auditwheel manylinux python-manylinux-demo
vphilippon       pipenv

If you have a way to contact these people (or are one of these people) please ask them to request a subscription to

(cc @dholth @dwight.hubbard @idlesign @JustinCappos @mayeut)


Maybe create an issue in a GitHub PyPA repo and ping them there?

1 Like

You can reach me at ehashman at debian dot org. (That’s my email on the wheel-builders mailing list :slight_smile: )

Thanks! I’ve subscribed you.

At this point I’ve added everyone that I’m able to and everyone that has reached out to me. Happy to add anyone that is missing but at this point there isn’t much else I can do to get the stragglers.

I think we can check the “Get the pypa-committers mailing list up-to-date (and a way to maintain this?)” checkbox here and I’ll be bringing PyPA as a PSF Fiscal Sponsoree forward for a vote shortly.


I do think we should send a mail saying “Hey, we’re going to start using this for PyPA-level decision-making votes now, since PEP 609 is now an accepted PEP” before we start the votes (in case there’s folks in PyPA who aren’t keeping up with all-the-things-around-that-governance-discussion. :slight_smile:

Maybe this is a topic for another thread, but in the PyPA as a PSF Fiscal Sponsoree vote, I’m noticing that it’s already very noisy, the votes are public and it seems like it will be somewhat annoying manual task to count the votes.

Is there any way we can move to an implementation where the vote is advertised on PyPA-committers, but conducted via discourse or Helios or some other system that counts the votes for you and doesn’t involve everyone on the list getting an e-mail every time someone votes?


@pganssle mentioned @

That it is ambiguous what PEP means when it comes to counting the votes proportion. Is it +1’s divided by all possible voters or by those who actually have casted a vote.
@pf_moore seems to agree and I think it’s reasonable to only count the ones who casted their votes too.

Per @dustin’s request, moving my comments on the voting scheme here.

In Dustin’s announcement of the PSF Fiscal Sponsorship vote, he said:

My response asking for a clarification:

As I said on the mailing list, my reading of the PEP is that “at least two thirds of voters” means people who vote. Looking at the full sentence,

Each PyPA committer can vote once, and can choose one of +1 and -1. If at least two thirds of voters vote +1, then the vote succeeds.

I’d have expected that if the intention had been two thirds of everyone, we’d have said “PyPA committers”, not “voters”. But it’s equally likely that we simply didn’t think of the ambiguity.

If we do make it “2/3 of people who voted”, we should really add a quorum mechanism so that proposals that don’t get enough votes can’t get in with minimal support.

1 Like

I agree that ‘voters’ should mean ‘people who cast a vote’, especially as it requires a supermajority.

I also agree with @pf_moore that a quorum requirement would make sense, though I don’t think it’s an urgent need. I’d be happy with a fairly low quorum threshold, like 1/3.

1 Like

Thanks everyone for the feedback. I’ll agree that I seem to have misinterpreted the PEP, I’ll chalk that up due to lack of coffee. It probably makes sense to amend the PEP to say:

- If at least two thirds of voters vote +1, then the vote succeeds.
+ If at least two thirds of recorded votes are +1, then the vote succeeds.

Why not just mute the thread after voting? I think the infrequency in which we’ll conduct a vote doesn’t merit this much overhead. Also, if we don’t actually need 2/3 of voters to participate, there’s even less emails to receive and less votes to count.

1 Like

A quorum with a fixed percentage of the voting populace will likely become a bigger hurdle over time, as many projects have inactive maintainers. For example, CPython has 172 core devs listed in the input to the voter rolls, of whom 82 were eligible to vote in the last election.

From what I can tell, on core dev promotions, absolute number of voters went up pretty significantly when it was switched to anonymous voting on discourse, and the number of votes each candidate has gotten since then is in the range of 20-40, so if CPython had adopted a 1/3 quorum without a qualification on who counts as “active”, no core dev promotions would have succeeded in at least the past several years.

If we’re worried about votes passing or failing due to lack of interest, I’d set a maximum quorum at a fixed number, like, “1/3rd of eligible voters or 10 voters, whichever number is smaller”. Possibly with a provision to extend the voting period if quorum is not met. Possible options for that would be:

  1. Extend until quorum is met.
  2. Extend by 1 week every time the vote expires without reaching quorum.
  3. Extend by 1 week every time the vote expires without reaching quorum for a maximum of N weeks.

If we are going to announce results here then I think that makes sense, otherwise I have not muted the thread yet as I’m waiting to hear the results. Muting also assumes your email client supports muting, though.

For what it’s worth if we choose something like helios we can switch to anonymous voting, which could help with fairness of some votes. E.g. if many people start voting for a proposal, other members don’t feel pressure for voting against. So I’m personally +1 on going Helios on this. Not sure how hard it is to setup the Helios voting, but I gather @EWDurbin has some experience he can share for the core python developers group.

PS. I’m ok with 1 week deadline. And announce result as it is afterwards. If we’re going to set any type of quorum we’d need to introduce some type of removing people from PyPa, to not make life difficult with people that walked away from PyPa packaging but still having their commit bits.

As mentioned downthread already, the issue with “recorded votes” is that there is no quorum established. If only one vote was recorded, then the vote would succeed.

I’d propose setting quorum to 1/3 of members of the list for simplicity.

For comparison, Debian defines its quorum as 3Q, where Q = 1/2 * sqrt(N) for N = number of developers. In the PyPA commiters case that would give a quorum of 10. 1/3 of 39 is 13.

(edited to s/29/39/)

1 Like