As a part of looking at the approval process for PEP 772 by pypa-committers, I did an audit of pypa-committers and noticed that the membership of the group (defined by commit access on GitHub) does not match the list of members on the mailing list.[1]
Given that it’ll be a non-trivial problem to try to resolve in general (with a possibly long tail), I’m proposing (after a short chat with the co-authors on PEP 772) that we do a different voting process – an off list vote on an issue on GitHub, via comments posted by each individual user.
The specifics are:
I post this proposal and advertise it in PyPA communication channels.
Someone from the PyPA committers seconds the idea (ideally, in this thread!).
We wait a week for feedback to roll in, to give people time and to see if there’s any showstopper concerns.
I post here once we have the final approach settled on (in case of changes to the plan/proposal based on the discussions).
I create an issue in pypa/packaging-problems (our catchall repo at this point) for the vote.
I advertise the issue on PyPA communication channels.
After the voting period, the issue is locked and I’ll do a count (like we’ve done for votes in the mailing list) – only counting comments that came from someone with the correct access.
Let me know if you have any concerns with this approach.
Which is maybe unsurprising – our governance model expected a disparate group of volunteers to keep two lists of membership of sync. I’m not posting the exact list of mismatches here, since it’s both a mix of emails and includes a few individuals who have their visibility of their PyPA membership marked as private on GitHub. ↩︎
I’m unclear from your description of this process who will be allowed to vote. If it’s a standard issue, won’t anyone (regardless of PyPA membership) be allowed to comment (and hence vote)?
Anyone will indeed be able to comment. However, we’ll only count votes from people who have the relevant access (since it’ll be associated with the individual accounts, and we can check individuals’ memberships accordingly).
Worst case, if we get spammed, we can make everyone with voting capability a collaborator on the repo and lock the issue so that only collaborators can comment.
Sounds reasonable. I’m happy to second this proposal if you don’t already have someone.
IMPORTANT EDIT: I was only seconding the proposal that we use a github issue for voting. I did not intend my comment to count as seconding a proposal that we go straight to a PEP 609 style 1-week voting period where people can only vote yes/no on the PEP as it stands right now.
Is there a reason to switch this to a more intensive process than before? I’m not opposed to using GitHub, but the idea of a repository that anyone can spam seems… less than ideal. Why not a private repository to avoid burning folks out who need to manage/count votes?
Partly because I looked and found, like, 30-40 people missing on the mailing list compared to the GitHub membership. And, given that the packaging council is the first (and only?) major governance vote we’re gonna have as a group, it feels appropriate to put in a bit of extra effort to ensure that we don’t disenfranchise anyone.
I’m personally OK with doing the extra work needed here (mostly coz I’ve done the relevant-access-required bits already as part of checking these memberships).
PS: I do want to resolve the mismatches as well, but that’s a bunch of comms work that I don’t have the bandwidth for doing at the moment – I’d prefer to get the PEP over the line rather than making this a blocker for it in any way.
The plan is unchanged – I’ll shortly file the issue on pypa/packaging-problems, and post the link everywhere relevant that I can think of (here, PyPA-committers mailing list, PyPA discord).
I’ve posted on the mailing list and will post on the PyPA discord shortly.
There’s another tool – we can limit interactions on the repository to only collaborators with GitHub’s moderation tools, which will still allow organization members to post their votes without the need for locking the specific issue. I’ve noted it on the GitHub issue for the vote since a longer list of folks can press the buttons for it.
1. Voting Quorum and Employer Influence
As written, a quorum of 3 Council members could allow two individuals from the same company to determine the outcome of a vote. This effectively gives a single company decisive power.
I would like to see a safeguard:
If only 3 members are voting, all 3 must be from different employers.
If 4 or more members are voting, the existing “at most two from the same company” rule suffices.
This ensures that no company can dominate decisions when turnout is low.
2. Electorate Definition and PSF Commitment
My understanding is that voting rights for the Packaging Council are tied to PSF membership, which requires either significant ecosystem contribution (contributing membership) or financial contribution (supporting membership).
I’d like confirmation that this is intentional.
In return, the PSF will commit to running Packaging Council elections whenever needed (e.g. mid-cycle replacements, no-confidence results), and not limit elections to only when PSF Board elections occur.
Is there a plan to run (normal) elections in parallel with PSF board elections?
3. Packaging Council ↔ PyPA Relationship
The PEP currently defers this to “whatever the inaugural Council decides.” That feels too open-ended.
I believe we should mandate that the inaugural Council propose a PEP that defines this relationship.
This PEP should go through public discussion and feedback before being adopted.
That ensures the community has a say in how Council authority interacts with existing PyPA project autonomy.
4. Conflict Resolution Between Councils
Right now, the PEP states that the Steering Council has final say if the Packaging Council cannot or will not decide. But what about conflicts when the two bodies make different decisions?
Is there a mechanism for the Steering Council to override a Packaging Council decision within a set timeframe (e.g. 1 month)?
Clarifying this escalation process is important to avoid ambiguity or deadlock.
Overall: I support the direction, but I cannot vote for this as written until the quorum safeguard, election commitments, PyPA relationship process, and conflict resolution rules are clarified.
I’ve edited my original post so that the link to it in the github issue points to my revised statement, but I’ll also post this here so that people who get this list via email see the update.
I didn’t intend when I seconded the proposal to use a github issue for voting, to initiate the week long voting process mandated by PEP 609 for governance votes. I do not believe we are ready for a vote on this subject yet, so while I’m happy to use the github issue for voting, I think we should have a separate discussion of whether we’re ready for a vote and whether everyone feels the PEP has addressed their concerns and views - much like I’d do as PEP delegate before starting the approval process on any normal PEP.
Overall: I support the direction, but I cannot vote for this as written until the quorum safeguard, election commitments, PyPA relationship process, and conflict resolution rules are clarified.