Implementing PEP 609: PyPA Governance

pradyunsg · July 21, 2020, 3:30am

Hurray! We have formalized the governance of the PyPA.

I think our next steps would be to actually implement the changes the PEP outlines:

Adopt PSF CoC on all the PyPA projects (and drop the PyPA CoC), using the files that GitHub recognises.
Get the pypa-committers mailing list up-to-date (and a way to maintain this?)
Work with the SC on the PEP process-related changes
- Determine a list of “who from PyPA can be a PEP sponsor” – this needs a dedicated discussion, and a committer vote IMO (so blocked on 2. above)
- Get clarity on the process for changing PEP 0 for namespacing.
- Get clarity on how to provide list of “PyPA sponsors” to the SC / PEP editors.

@EWDurbin any thoughts on how to make 2. happen?

hugovk · July 21, 2020, 6:10am

This can be done by putting (for example) CODE_OF_CONDUCT.md in an organisation-wide GitHub - pypa/.github: Community health files for the Python Packaging Authority repo, so it doesn’t need to be added individually to all project repos.

dustin · July 21, 2020, 3:26pm

I created https://github.com/pypa/.github/ as well as https://github.com/pypa/.github/pull/1/ to add the PSF CoC.

dustin · July 29, 2020, 3:27pm

For #1, I’ve merged https://github.com/pypa/.github/pull/1, I think next steps would be removing the PyPA CoC from http://github.com/pypa/ repos – @hugovk perhaps you’d be interested in doing that?

For #2, I’ll work on setting up this list.

hugovk · July 29, 2020, 6:26pm

Sure, something like The PyPA has adopted the PSF code of conduct by hugovk · Pull Request #70 · pypa/get-pip · GitHub?

The existing link is to Code of Conduct — PyPA documentation, 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 .github/CODE_OF_CONDUCT.md at main · pypa/.github · GitHub or elsewhere?

hugovk · July 29, 2020, 6:39pm

On that PR, @pradyunsg suggested linking directly to https://github.com/pypa/.github/blob/main/CODE_OF_CONDUCT.md because it skips needing to click through an extra link to get to the relevant reporting details, so I’ll go for that one.

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

pradyunsg · August 9, 2020, 4:21am

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

pradyunsg · August 10, 2020, 9:59am

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

dustin · September 10, 2020, 9:38pm

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 pypa.io
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 packaging.python.org pypa-docs-theme interoperability-peps pypa.io
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 https://mail.python.org/mailman3/lists/pypa-committers.python.org/

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

hugovk · September 11, 2020, 6:25am

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

ehashman · September 11, 2020, 4:00pm

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

dustin · September 11, 2020, 6:03pm

Thanks! I’ve subscribed you.

dustin · September 30, 2020, 5:28am

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.

pradyunsg · September 30, 2020, 5:45am

Done.

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.

pganssle · September 30, 2020, 2:36pm

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?

webknjaz · September 30, 2020, 3:09pm

FTR

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

pganssle · September 30, 2020, 3:10pm

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:

pganssle:

Clarifying question about how PEP 609 is to be interpreted. The text is ambiguous in that it says “If at least two thirds of voters vote +1, then the vote succeeds.” If I am reading you right, you seem to be interpreting voters to mean “anyone who has a right to vote”, but I had interpreted it as “anyone who casts a vote”.

If you interpret voters to mean “anyone who can vote”, that means that failure to vote within the 7 day period is equivalent to voting -1, which seems like it’s putting a thumb on the scales against any proposal passing (particularly since -1 votes count double!).

I would expect that we would wait 7 days and then tally up the votes, and if ⅔rds of votes cast are +1, the proposal passes. If we achieve 26 +1 votes or 13 -1 votes in a period shorter than 7 days, we can end the vote early since further voting cannot affect the outcome.

pf_moore · September 30, 2020, 3:24pm

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.

takluyver · September 30, 2020, 3:27pm

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.

dustin · September 30, 2020, 4:28pm

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.

Topic		Replies	Views
Question: Is there a canonical repo for pre-governance and pre-PEP discussions and drafts? Coordination	17	598	November 29, 2023
Proposal to create a Python Packaging Council Packaging	101	5331	August 14, 2023
PyPA Governance - A "Status-Quo" Model Packaging	9	1791	November 6, 2019
What do you want in Python packaging's future governance model? Packaging	28	2144	September 6, 2023
PEP 609: PyPA Governance PEPs	42	6172	July 21, 2020

Implementing PEP 609: PyPA Governance

Related Topics