PEP 772: Packaging Council governance process (Round 3)

Packaging Coordination
21

I agree that this is probably true. However, I would refer back to my points on both:

  • (a) those who for whatever reason are not able to become, or do not want to become, members of the PSF, and

  • (b) that because the quoracy requirement for Packaging Council votes is 50%, elections will by definition require over half of PSF members to express a preference, meaning that potentially hundreds or thousands of individuals who are not engaged in the packaging community will be required to vote. Apathetic voters, or those voting only by name recognition, are in my opinion something that should be strongly avoided.

    Quorum requirements generally exist to ensure that a plurality of those affected by an election participate in it – by drawing the net of electors so widely, I think we do face a real risk here.

A

3 Likes
22

I thought the proposal was that the quorum was 50% of electors, where electors are PSF members who have declared that they wish to vote in the PC election. It’s somewhat weird to imagine that only 50% of people who have explicitly declared that they plan on voting will then actually vote, so I think the definition is confusing at best, but I don’t think it technically requires 50% of PSF members.

In fact, I think the opposite problem arises here - quorum isn’t what matters, what really affects representation is that people have to actively request the right to vote in order to even be considered part of the “affected community” from whom the quorum is calculated.

2 Likes
23

My turn to misremember the PEP! Indeed you’re right, the specific section is:

The eligibility of Packaging Council Electors is equivalent to the Article IV, section 4.2 voting membership defined in the PSF bylaws. Should those bylaws change in the future, the eligibility of Packaging Council Electors will similarly change to match. Packaging Council Electors must affirm their intention to vote in Packaging Council elections in a manner and process similar to PSF Board voting membership affirmations.

(emph. added) I had forgotten this part, I’m sorry for getting things wrong here.

A

24

Thanks @bernatgabor and others for providing your feedback on the PEP. Heads up that this will be a long, and probably scattershot, response!

ObFullDisclosures: I am writing this response primarily as a co-author of this PEP, and have not had detailed discussions with my co-authors about the latest round of replies so their opinions may differ. I’m also a sitting member of the Steering Council (PSC) and may serve on the council that votes on this PEP’s acceptance. But of course may not! given the PSC elections later this year.

Governing documents are incredibly difficult to draft. You want to both lock down certain aspects and leave others underspecified, so that you end up with a functional governing body that also has the flexibility to figure things out on the fly as circumstances require. You have to at least consider every corner case[1], every possible avenue for subverting the “will of the people”, when even figuring out what that “will” is and who the “people” are is challenging. In the PC case, it’s complicated even more by the existence of multiple deliberation/decision making bodies, the loose nature of the PyPA, the delegation of powers, and the diverse and diffuse interests.

I’ll also point out that the current state of the PEP is the result of many hours of online and in-person deliberation, notably at PyCon 2025 amongst @geofft, @willingc, the PEP authors, and others at the packaging summit, the input from the PSF Board, and other input from folks online, in-person, in public, and in private. This is also the 3rd round of DPO threads, and everyone knows how hard it is to keep up on DPO.

As others have pointed out, while this PEP is modeled on the PEP 13, it must by its nature be different. In many ways I think it’s harder to govern packaging than it is for CPython. There’s a much longer and broader tail to any changes in the packaging ecosystem, and it reaches and touches (in my subjective opinion) vastly more unrepresented users than CPython evolution does. Packaging also long tradition of being a more decentralized effort, which is both good and bad, and which both has its proponents and detractors.

And yet, one thing we can all agree on[2] is that packaging is incredibly important to Python’s success, past, present, and future.

One thing that hasn’t been mentioned yet is why the PSF is a key partner in the future of packaging: the PSF runs and funds PyPI, and I think everyone can agree it’s the linchpin underlying nearly all packaging efforts. Clearly, any proposal that touches PyPI will have to have PSF buy-in, explicitly or implicitly, or it won’t go anywhere.

On to some specific replies.

I don’t think this is a practical concern. Quorum must be 3 non-abstaining members, which means the other two must explicitly abstain for the remaining 3 to pass the resolution. Even if that happens, and 2/3 of the non-abstaining members come from the same employer, and they pass a resolution that the majority of the packaging membership disagrees with, there are, IMHO, enough checks and balances in place. E.g. a vote of no-confidence can be called by the membership with a second required, or the Steering Council may call such a vote with no second required. And even if the PSC were compromised, the PSF Board can override a PSC call of no confidence. Because sitting members of the PSC are explicitly disallowed from being on the PPC, while collusion is always possible, it would take a lot more effort than I think is practical or realistic. And besides, if the PPC takes a particularly unpopular decision, the most likely outcome is that it would just get ignored. Individual project maintainers will always have autonomy over their projects, the PSF owns PyPI, and I simply don’t believe that the resulting hue and cry will ever stand.

As someone else said, I choose to believe in the good intention of all of the people involved. This has served the PSC well so far.

This is correct.

As you and others have pointed out, we tried really really hard to make the category-based approach in earlier versions work, but we just couldn’t. Issues that were unsurmountable include the resulting number of corner cases, unrepresented stakeholders, the balance between volunteers and paid contributors, the balance between open source and commercial interests, increased opportunity to “stack the deck”, problems bootstrapping the vote, and other considerations and inequities that ultimately doomed the previous approach. I don’t have a point-by-point breakdown of all the issues that we identified, but I will say that trying to come up with a broad and equitable membership plan under the previous version was the most contentious issue, and the more we found flaws in that approach, the more the authors and other participants soured on it. I simply don’t think it can be made workable. Speaking as one of three co-authors of the PEP, I have zero motivation to go back.

Is the PSF membership requirement perfect? Of course not! But I strongly believe it’s the most equitable and workable. PSF membership is open to any stakeholder who wants to participate. People choose not to join the PSF for their own personal reasons, and that’s fine, but I also firmly believe that even non-PSF members will have a significant voice in the direction and decisions of the PPC, regardless of whether they can run or serve. No one will agree with every decision, but you will be able to voice your opinion and argue your case, when done with respect for our colleagues and our community. I strongly believe this is the most democratic, inclusive, and pragmatic way to structure the voting membership.

Ideally, yes, for practical reasons. Administering elections is a lot of work. Operationally, it just makes the most sense to conduct Board and PPC elections at the same time, but keep in mind there are provisions for “off-cycle” elections, e.g. the initial council seating and vacancies, either for no-confidence results or otherwise. These should not be the norm. There are also provisions for PSF voting members to only vote in Board or PPC elections, as they choose.

This is deliberate, and relates to the flexibility mentioned above. A likely result could indeed be a PEP process as you describe, but mandating this in the governing constitution of the PPC seems to me to be handcuffing the PPC’s and PyPA’s options to hammer out a workable relationship.

The PPC derives its authority through a standing delegation from the PSC, exactly as the current packaging delegates do. That delegation of authority also means that the PSC is the ultimate technical decider, and just like any other technical Python decision, the PSC has the authority to overrule. This is more complicated than say, delegation for CPython decisions exactly because it overlaps with services like PyPI that are owned and maintained by the PSF.

Let me give an example. Say the PPC decides to give all packagers free, unlimited space on PyPI, and the PSC doesn’t veto that decision. The Board and PyPI admins would be well within their rights and responsibilities to override that decision, or just say “no”. There’s no practical way for the PPC or PSC to force the PSF or PyPI to go along with any decision that negatively impacts PyPI.

That said, the PEP authors deliberately left the PSF out of the direct decision making process because Python has an incredibly strong tradition of separating technical decision making from community, legal, fiscal, and other considerations. This is even though there are lots of cases where the relationship between the PSF and PSC is already a bit fuzzy. And yet, so far, it’s working.

I strongly believe that the relationship between the PSC and PPC as defined in the PEP will similarly work well for us, but if there is specific language that you think needs clarifying, I’m[3] are open to suggestions.

Given that this is already a long response, I’ll leave it here, but I’ll also try to respond to select comments in the other follow ups.

  1. knowing ahead of time that you will miss some – as anybody who’s written test code trying to get to 100% coverage can attest to ↩︎

  2. I hope! ↩︎

  3. and I presume my co-authors ↩︎

6 Likes
25

True, but PSC voters must be core devs, which is an even more select community. I think there are less than 200 core devs, of which many are effectively inactive, and many more do not participate in elections. And yet, the PSC is extremely diligent in trying to represent the needs of the vast majority of Python users, even when that’s incredibly uncertain, and knowing that there are millions of users who don’t even know anything about how Python is developed, what core devs do, or what the PSC even is.

@tim.one can probably provide references, statistics, and witty anecdotes, but I bet it will pretty much boil down to “that’s true of every election ever held”.

If as above the PSC is any indication, I suspect the majority of PSF voting members won’t participate in PSC elections at all. I predict outcomes that “make the most sense to the majority of the most engaged stakeholders”, and if the results are really horrible, there are enough checks and balances that it won’t be catastrophic.

Look at how difficult it was for @pradyunsg to reach as wide a possible audience for feedback and voting on this PEP, just within the PyPA, and how these issues are now being raised on the third round of DPO discussions. Packaging discourse is open (obviously a good thing), but I think you’re underestimating the friction in just being aware of where and how it happens. And that’s not counting the incredible friction in just keeping up with DPO megathreads.

I believe the explicit description of delegation from PSC to PPC makes that clear – or at least no less clear than the current standing delegations. But as I mentioned before, if anyone can propose specific language to clarify that, I’m open to it.

3 Likes
26

I’m skeptical about that. As an example, PEP 13 was amended to mandate Bloc STAR voting for PSC elections, and it’s been difficult to find a provider that meets all our needs in time for the coming PSC elections.

Solely as a co-author of this PEP, the answer is generally “no”. The PSF does not have a mandate or tradition to make technical decisions for Python, and this PEP doesn’t change that. I use the qualifier because as I mentioned above, the PSF owns, maintains, and funds PyPI, so it does have a significant interest in an important part of the overall packaging ecosystem. Even so, PSF staff members are explicitly prohibited from serving on the PPC.

4 Likes
27

I hope that if the PSF membership requirement stays, that you’ll consider self-certifying as a contributing member, and running for the PPC. I’d wager you’d become a founding member of that council. :smiley:

2 Likes
28

Who’s to say which PSF members have no direct interest in packaging, if there even are any? Packaging touches 99.lots-of-9’s% of all Python users. Can you elaborate on your concern?

29

Again, given the enormous push back we received for the category-based approach in earlier versions of this PEP[1], I think it’s going to be very difficult to make this work. See my post above for the challenges I think you’ll face.

  1. it was the most contention aspect ↩︎

30

Earlier versions of the PEP did not have this requirement, but it was added to close a loophole. Unfortunately I don’t remember the details, but maybe @pradyunsg, @Deb, @geofft, @willingc or someone else remembers.

31

Something that occurred to me here is that basically any list of people is bound to have some number of people who do not wish to be associated with that list, but may want to participate in voting. Not that it’s the same thing, but we had people/projects who didn’t want to be part of the PyPA even though effectively all that meant was you had a CoC and got stuck under the PyPA org on GitHub.

This also has to tie in with a need to ensure there isn’t sock puppets being used to vote (so something like discourse accounts wouldn’t work).

It’s probably an unsolvable problem, even trying to create a list of just people who are allowed to vote with no other implications would exclude unknown people who otherwise wanted to remain anonymous due to the need to prevent from ballot stuffing.

PSF membership at least allows a very broad and diverse group of people to vote, and given the packaging council is likely to still operate by consensus where possible— even someone who can’t vote can participate in discussions and influence that way.

3 Likes
32

Pretty much, yes. Communities differ in various ways, and there are no studies of PSF voter behavior. Worse, we haven’t been using election servers that even allow for obtaining anonymized ballots, so have had no way of quantifying anything other than final results.

In general it’s true that voters in America are typically ill-informed about the issues. Partly because effective “messaging” appeals more to emotions than facts, so there’s scant incentive for the big-dollar political campaigns to focus on facts.

The advantage of name recognition is a matter of human nature, though, and almost certainly universal, independent of election specifics. Although, e.g., I’d bet a dollar that Guido would get more votes if his name were listed at the top of the ballot than the bottom. Some number of voters are just in a rush.

We try to counter that by using election services that randomize the order of candidate names on each voter’s individual ballot. Bias due to candidate name order is a well-established research result.

That said, “name recognition” is far more a concern in methods that limit the number of candidates you can support. This creates fear of “wasting your vote” on someone you really want but fear can’t win. Safer then to vote for the least repulsive of the candidates you think can wink, and give your actual favorite no support.

That’s a pretty horrid “user experience”. Under the “no limits Approval” method we’ve been using, there’s no such thing as a wasted vote. Approving of everyone you can live with doesn’t hurt any of their chances. You may be surprised then at just how much support that candidate you thought couldn’t win actually gets. They probably won’t win anyway, but the extent of the support they do get is wholly visible in the final results, and can definitely affect how the next election goes.

However, Approval is strictly a binary thing: you approve of a candidate, or you don’t. So consider:

  • Robin’s positions are a revelation! You’re extremely impressed. You’d give a year’s salary to see them elected.

  • Pat’s positions are nothing special, but when growing up you had a neighbor who had a cat with that name you really liked. So, what the heck, approve of them too.

The newer “bloc STAR” voting method the Steering Council will be trying doesn’t specifically try to address that, but I believe will help. It also has no limits, but rather than yes/no, you give each candidate from 0 through 5 stars. So give Robin 5 and Pat maybe 1. Meaning you can live either either, but vastly prefer Robin. Then you’ve expressed your real beliefs,

Why not\ expand the scale to, e.g,.,100 stars? You certainly could, but studies showed it doesn’t deliver significantly better results. “5 stars” has the advantage of resonating with some popular rating schemes for other things, from restaurants to movies, so reduces the initial “novelty burden” for new STAR users.

In modern large-scale voting simulations, STAR does deliver better results than Approval, although both are fine methods.

Let’s see how that goes. I expect people will like STAR better. and the service we intend to use does allow downloading anonymized ballots for detailed analysis of voter behavior. If it works out, I hope all PSF elections will transition to use STAR instead. Scaling to hundreds of voters is no problem for it. Or to thousands. It’s a bit harder/slower to tally than Approval, but no challenge for a computer even with millions of voters and hundreds of candidates.

But there is no method that takes votes seriously that can overcome voter indifference, apathy, lack of knowledge, or ill intent. That yahoo on the Web who drives you crazy with their ill-informed and bad-natured posts? Yup! Their vote counts just as much as yours :wink:.

3 Likes
33

I hope it does too! I remember really wanting STAR when the original vote mechanism was picked, but gave up on it when there wasn’t a good service to use to use that method.

2 Likes
34

And it’s good to know that the other remaining hardcore election nerd (i.e., you) appreciates STAR too :smiley:.

I’m not at all worried about the method, but we still need to approach the new service with caution. We’ll be one of their first “for real” dead serious users, and “things happen” even with time-tested services. I ran some little test elections last December, and it was remarkably solid on those. The few issues we found were quickly addressed.

Our @EWDurbin (who will actually administer the SC election) tried their own test elections a month or so ago, and even reported that the service’s email facilities were less hassle than those of the service we’ve been using for Approval, which will save them time and busy work too.

So it’s looking good so far!

1 Like
35

If the requirement stays, I’ll feel compelled to self-certify in order to vote. I will not vote in PSF elections, and I will attempt to drop my PSF membership once I have voted for the PPC. If I run for the PPC, and that requires me to remain a PSF member for my tenure on the PPC, I will do so reluctantly. So it’s not a technical impediment, but it feels like an abuse of the idea of PSF membership to me[1].

By the way, what are the rules on how candidates for the PPC can vote? Can they vote for themselves? It’s not a question that’s come up for me before :slightly_smiling_face:

  1. Please don’t ask me why I feel the way I do about PSF membership. It’s complex, and not relevant to the topic at hand. ↩︎

4 Likes
36

If that got a reply, I missed it (it’s not easy to follow intricate discussions here, and the search function isn’t really useful for this), so apologies if this is duplication. We’re at the mercy of the election service we’re using.

  • The service currently used for Board elections does NOT support changing votes. Nothing can be changed after you submit your vote.

  • The service that will be used for the next SC election WILL support changing votes, as often as you like before the election closes. This isn’t yet actually implemented on their end, but is planned to be completed well before the SC election starts.

This isn’t shallow to overcome. The election methods used in Board+PC and SC elections are different, and no single service supports both methods. I hope all PSF elections will eventually move to the election method the SC election will be using, but that’s not yet the case.

All voters on all services see the same ballots (although the candidate names appear in a randomized order for each voter), and there’s nothing to stop any voter from voting for anyone they see. So, yes, a voter can vote for themselves.. While voting for oneself was sometimes frowned on when I was a child (many decades ago), I don’t think it’s viewed as being even slightly unethical anymore.

In any case, all services take privacy very seriously, and not even the PSF’s election administrators can learn anything about how you voted. It’s as private as the service’s internal computer systems, and your browser connection when voting.

1 Like
37

That particular question was about the (manual) handling of the vote on GitHub for the PyPA members to approve the PEP. In particular it was a question of if someone who has voted changes their mind on the PEP based on the discussion here, what can they do? It may be irrelevant given that the vote is flawed due to not having been properly seconded, though.

IMO, once this round of discussion has died down, and the PEP authors have made any changes they want, a new vote should be called to approve the PEP. That vote should be yes/no only, with no discussion allowed, and a clear proposer, seconded, and voting period duration stated. That’s the existing PyPA voting process, just explicitly formalised because this is a particularly significant vote. A “no” decision would mean the PEP needs to be revised, so people with reservations who want further discussion should vote no (instead of starting the discussion while the vote is in progress).

3 Likes
38

One thing I’d request - can the Packaging Council (or the PyPA) document somewhere that’s explicitly for people interested in packaging, how to register to be eligible to vote in the Packaging Council elections? This means:

  1. Explaining the PSF’s rules on eligibility for membership, with particular emphasis on “if you actively participate in packaging discussions on Discourse, there’s a good chance you spend enough time doing so to qualify for the community involvement criterion”.
  2. Pointers to whatever web pages you need to go to in order to register for membership and for eligibility to vote. I’ve heard anecdotal evidence that people find it frustratingly hard to be sure they have registered for PSF elections, I’d like it if the packaging community didn’t inherit those problems.
  3. Ideally, an explanation of how to register to vote in Packaging Council elections, while opting out of communications on any other PSF matters (including PSF votes). I don’t know how many people will be in my position of wanting to vote for the packaging council, but not be involved in the PSF, but I think it would be good to make it explicit that this is a valid position (and describe how to do it).
2 Likes
39

Ah, my apologies for the noise! I totally missed the context. I’ve found that the lack of visible and usable threading in this kind of forum makes it much harder to follow intricate discussions, and especially when you come into one late (as I did here, noticing it only because I was recently tagged in a post here).

Sorry to say, I know nothing about how voting on GitHub works.

1 Like
40

I think that is a reasonable, important request.

@barry asked me to chime in about discussion during the packaging summit and on the PEP. I’ve quoted @dstufft’s message as it covers most of the issues that were discussed in depth during the packaging summit breakout group.

We also discussed tradeoffs of different approaches including:

  • who is included/excluded
  • does the approach move us closer to serving the packaging needs beyond tools and address foundational things like standards and communicating effectively to provide guidance for users from different domains
  • does it include stakeholders across different domains who have devoted countless hours to improving packaging workflows to support different user needs
  • does it value the expertise of those that have worked on PyPI and tools within PyPA without excluding the expertise of those working with tools in high performance computing, science, and data science
  • do we have the capacity to implement and carry out effectively a proposed approach (in other words, who will do the work)

The proposed solution, as @barry explained, provided the highest likelihood to meet the goals for the future of packaging and delivering software to Python users across a broad spectrum of domains.

4 Likes