PEP 772: Packaging Council governance process (Round 3)

Packaging Coordination
1

On behalf of my co-authors, I’m happy to share that we’ve published an update of PEP 772, Packaging Council governance process (see also round 1 and round 2). This is the third – and hopefully final – round of changes before we can begin the formal approval process.

Please use this new thread for any additional feedback of this latest revision.

This version incorporates all the changes discussed at PyCon 2025’s Packaging Summit, as well as feedback from the PSF Board, through our co-author @Deb. In general, we’ve gotten very positive reactions to this version.

The list of significant changes are summarized as follows:

  • Nominees to the PC must themselves be PSF voting members.
  • Clarity is added around how PSF voting members are informed of and may opt-in or -out of PC elections, including the ability to do so independently of their participation in Board elections. This also aligns affirmations of the intent to vote in PC elections with a manner and process similar to PSF Board election affirmations.
  • We’ve removed specifics about the voting process, including the explicit mandate for Bloc STAR, in order to ease the administration of the election by the PSF Staff, and to align the election process with PSF Bylaws. Since PC elections are run concurrently with PSF Board elections, and administered by the same staff members, and due to the (current) difficulty of finding a suitable open source platform for PC elections, this PEP leaves the mechanics of the election process to the PSF and the Returns Officer. This is a practical solution that allows for fair, transparent elections as well as flexibility to change the election mechanics in the future if such a platform is identified.
  • The PEP now describes “off-cycle” elections, since the initial election, and any future post-recall elections may not align with the annual PSF Board election.
  • There’s some slight rewording about the prohibition against sitting SC members from serving on the PC.
  • A better description of what happens in partial (i.e. cohort) elections to ensure the “no two members from the same employer” rule.
  • The PC and its participants are explicitly placed under the PSF Code of Conduct.
  • Explicitly mention that PSF voting members can opt out of PC elections independently of their choice to participate in PSF board elections.
  • The Returns Officer is nominated by the PSF Board.
  • The PSF Board has the responsibility to certify the PC election.
  • In the unlikely case that vacancies are unfillable by the normal process, the Board and SC consult to fill the vacancy.
  • While the SC still has discretion over calls of no-confidence, the Board can override the SC.

@pradyunsg, @Deb and I are incredibly grateful to everyone who has contributed their energy, constructive feedback and suggestions, and insight into this final round of edits. This is a much better proposal because of your participation.

13 Likes
2

The updated PEP looks good to me, and the structure remains such that the PSF Packaging WG’s endorsement still applies.

6 Likes
3

One thought that came to my mind recently - could we have some discussion of the transition process to the new council?

My approach in the existing PEP delegate role is that I don’t confine myself to waiting for PEPs to be submitted for approval, but rather I’m actively involved in the process of developing PEPs, providing specific guidance on what the PEP needs to say if it’s to get approved when it is submitted. That’s very much based on what I’m looking for in a successful proposal, and I don’t want to assume that my decisions would match those of the packaging council in all cases.

It does mean that the transition affects more than just PEPs that have been submitted for approval, though.

So what should happen when the packaging council proposal gets approved? Should I stop making statements along the lines of “The PEP needs to cover XYZ if it’s to get approved” or “As PEP delegate, I think…”? What needs to happen with proposals that are in progress (I’m particularly aware of the wheel variants proposal here) - is it OK to assume that people will understand that under the council, my previous advice may no longer be as authoritative as it was when it was given? Or am I making too much of a big deal about this, and it doesn’t need to be made explicit?

I’d also be interested to know whether the council will continue to be involved in PEP discussions the way I have been in the past, or whether they’ll take a less active role. But that’s something for the initial council to decide, rather than something we’ll define up front.

7 Likes
4

It’s been many years since we transitioned from BDFL to SC for core Python, but I’ll try to give some thoughts based on my experiences there. Keep in mind that many operational aspects of the Packaging Council are deliberately left unspecified in 772, just so all the stakeholders and active participants can figure out the right vibe. The PC is different than the SC, so it will naturally find its rhythm over time.

Of course, you may decide to run for the PC in which case, if elected your voice would continue to be authoritative even if as part of a council. It will absolutely continue to be expert opinion and highly regarded either way!

One thing I try to do when posting publicly[1] is to be explicit when I’m posting as myself or as a representative of the SC giving official SC statements. I’m sure I’m not consistent (I don’t want to have to say that for every single post I make), but I’m very diligent when I’m posting on behalf of the SC, and try at least at the start of a thread, to say “I’m just speaking as myself”. Just because you do or do not serve on a deciding council doesn’t mean you can’t participate! You just have to be a little more careful so your comments aren’t misinterpreted as official positions. It might take a little more care at first, until the PC is well-established.

  1. at least for the terms that I’ve been on the SC ↩︎

5 Likes
5

A minor update has just been published. It adds this language:

The Packaging Council will moderate its spaces and support PSF Code of Conduct enforcement as appropriate in the area.

It also records the resolution of the PSF Board to approve the PEP as part of the special approval process. We’ll add the link to the relevant PSF Board minutes when they’re published.

3 Likes
6

For whatever my opinion is worth, I’m a big fan of this :slight_smile:

4 Likes
7

There’s a related topic that I created earlier today:

1 Like
8

The PyPA committer vote has been started.

9

Here’s some concerns I have:

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.

:backhand_index_pointing_right: 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.

2 Likes
10

I’ve hesitated to write this up this for a while, as it almost feels like this PEP is a done deal and it’s too late, but following Bernat’s earlier post I decided to post this.

In summary, I support the PEP and the concept of a Packaging Council [1] (clearly a lot of work has been put into it, over many years!), but I have a couple of concerns as the proposal currently stands.

I think making the electorate the members of the PSF is the wrong choice.

The Python Software Foundation (PSF) does a lot of good. For disclosure, I am a member of the PSF, and have been for several years. Notably, the PSF supports and funds the services required for PyPI to operate and funds the ‘developers in residence’ programme. Becoming an individual member of the PSF requires a financial contribution (min $25/yr, suggested $100) or a self-declaration of spending 60 hours/year volunteering in the community.

However, the PSF does not play an active role in core development. I think this is a good thing, and the PSF focuses (from what I can tell as an outside observer) largely on events, community engagement, events, etc. For better or for worse, it is easy to be an active partipant in core development, PEP discussions, or standards development without directly interacting with the PSF or its processes [2].

I do not think it is right to require membership of the PSF to participate in the governance of a part of the project, unless we require it for contribution to all parts of the project.

Under the PEP as written, non-members of the PSF are ineligible to serve on the Packaging Council and ineligible to vote for its members. Many people active in the Python community, including several core developers and triagers, are not members of the PSF, either through choice or inaction. For example, some individuals may not wish to join a membership organisation for personal reasons. Some may disagree with a decision made by the PSF and choose not to be a member, or to resign an existing membership. Others may not want to have an affiliation with/membership of an organisation based in a particular country.

I do not think we should exclude any of these groups from particpating in how Python packaging is governed. We may disagree with the choice not to join the PSF, but that should, in my opinion, be entirely distinct from technical considerations of standards and processes.

The clearest parallel is status as a core developer: the right to vote in Steering Council elections has no relation with the PSF.

My further concern with a very broad membership class is that electors will either (a) not know what or who they’re voting for, leading to low engagement, or worse (b) not know what they’re voting for, and vote randomly or for ‘recognisable’ names, leading to a popularity-contest style election. This is bad for obvious reasons.

I worry that declaring the entire PSF voting membership as electors for the Packaging Council will lead to these problems, whilst not materially affecting the class of people who participate in activities under the Council’s remit.

Packaging is a (very) important topic, but those who participate in standards discussions and implementing tools form a relatively small group. I do not believe that being an elector for the packaging council will cause the ‘man on the Clapham omnibus’ to become materially more engaged with the packaging community, although I would love to be proved wrong. Packaging is currently incredibly open, with (almost) all discussions happening in the open on Discourse, and all major packaging-related projects being open source. Becoming involved in packaging work is very low friction, and a testament to the community.

I have always been of the opinion that rights and obligations are two sides of the same coin. In this case, the right of voting, in my opinion, should come with the expectation of active participation with packaging in Python, save just as a user. For example, downstream redistributors are absolutely engaged in (re-)packaging, but are perhaps unlikely to engage with the PSF – their primary affiliation would be to the OS/distribution that they volunteer for. As such, I personally support the previous model proposed by the PEP, where there is a defined electorate of ‘those engaged with packaging’, in whatever appropriate sense is used to define ‘engaged’.

I appreciate that using PSF voting members as the electorate makes some things easier in implementing the governance process, but for these reasons I do believe that it is the wrong choice to make, both in potentially excluding community members, and in including many who may be under-informed or not particularly engaged in the PPC’s work. Further, I believe some matters are complicated, including the differing roles of the Steering Council & PSF Board in overseeing the Packaging Council, and which has ultimate authority.

Finally, I would mostly echo Bernat’s point on conflict resolution. I raised this point before, though not on Discourse. The PEP currently states:

The [Packaging and Steering Councils] would work together on issues that intersect the packaging domain and language stewardship …

It also says elsewhere that should the Packaging Council not be able to decide a matter, the SC may make a binding decision.

I take this to mean that if the Packaging and Steering councils disagree on something & it can’t be resolved by consensus or redrafting the proposal, the SC can override the Packaging Council? If so, I think it would be useful to clarify this explicitly in the text. Clearly we hope this will never happen, but governance documemts are the place to specify what happens when things go wrong, to prevent future arguments.

Again, thank you all for your work on the PEP thus far. As I said, I haven’t been sure about writing this post, and as such I am sorry it comes so late.

Thank you for your consideration,
Adam

  1. Python Packaging Party was a missed opportunity! ↩︎

  2. obviously indirect interaction is inevitable, simply via PyPI! ↩︎

2 Likes
11

I’ll say going ahead the PSF will play an active role. They’ll be funding the election processes, so this would no longer hold true. So there’s some incentive in them getting something back in return for this.

12

Personally I wouldn’t count administering the election as active participation — it’s a service that could be entirely delegated to a commercial provider, for instance. The PSF provide similar administrative services to the SC/core developers, but again nominally it could be fully outsourced, IIUC.

However, it is a good question — does the PSF intend or want to become (corporately) more active in the governance and development of packaging standards etc? My understanding is that the Packaging Working Group (under the auspices of the PSF) has been de facto defunct for several years.

A

1 Like
13

I’m confused as to what parts of the document you derive this from, the part you link says about the Steering Council:

If the Packaging Council cannot (e.g., by lack of quorum) or wishes not to come to a decision on its own, it can also refer the matter to the Steering Council, whose decision on the matter will be binding.

Which, to me, very clearly reads as not a disagreement, but that the Packaging Council can choose to refer the matter the Steering Council, rather than making a decision itself.

Further reading through what the document has to say about the Steering Council:

Steering Council is not well-placed to make decisions over Python packaging matters directly

If you could elucidate on what exactly you mean by a disagreement and where you think this document indicates that the Steering Council would take precedent that would help me a lot in understanding what you mean here.

14

I think this issue is unlikely in practice. Intentionally taking advantage of low turnout borders on bad faith behavior. But it should be easy enough to fix.

Can we get a simple amendment in for this part? Bernat’s proposed solution looks straightforward to me, and it’s hard to un-see a problem once it’s been pointed out.

I agree that there are ways in which it’s not ideal. Setting aside the fact that someone may not want PSF affiliation, I’m sure many eligible people are unaware that they already meet the time commitment for Contributing Members.

Accepting that it’s imperfect, is there an obvious alternative? The only other suggestion I recall was pypa-committers, which excludes even more of the people we want to include.

To me, this seems like a case in which we must compromise at some level. You said “the wrong choice”, so what are the better options?

I currently favor what’s in the PEP on the basis of it being more inclusive than pypa-committers.

15

I agree that this feels like the wrong choice to me (and I strongly agree with all of the points @AA-Turner makes here). Personally, I’m not a PSF member and have never had any interest in becoming one. Sure, it’s easy for me to do so, because I certainly spend 60 hours/year on volunteer work, but I’ve no interest in being a PSF member for any reason other than to vote in the packaging council elections.

Furthermore, I’m uncomfortable that PSF members who have no direct interest in packaging can vote. While most almost certainly won’t, I’m concerned that some might (either from a sense that it’s something they “should” do, or because they have some type of single-issue interest). We currently have a very active and engaged packaging community, and this decision risks, in my view, diluting the impact that community has on the governance of the packaging ecosystem.

Certainly I can see the argument that there’s no easy way to capture “the packaging community” in a straightforward way. But is that a reason to pick a flawed approach? This is arguably the single biggest change to how the packaging ecosystem is governed, and I think we owe it to the community to do it right.

My preferred option would be to create a specific packaging voters list. It could be seeded with the people with commit access to PyPA projects (which isn’t precisely the same as the pypa-committers list, so maybe we need to merge the two). And in addition, we could allow people to request that they be added to that list - doing so would be no more problematic than the existing PSF “self declaration” process. The numbers would be relatively small, so if we added a manual review process to verify requests and the initial seed group, that seems reasonable. I’d be willing to help create that initial voter list. I know something along these lines was discussed previously, and dismissed as being a lot of work, and having the potential to miss important contributors, but I’m not convinced it’s so much worse than the PSF membership approach (it trades more up front effort for a more focused list - which is the right trade off IMO).

I’m sorry that this is only coming up now, but honestly, I hadn’t realised that we were as close as we seem to be to the point where this happens. It’s quite different from the normal packaging PEP process, because of the voting mechanism.

By the way, some specific questions on the voting process:

  1. How long is the voting period? I’m concerned that if there’s a deadline, there’s pressure on this discussion to reach a conclusion ASAP, just to meet that deadline. There’s no mention in the issue of the voting period.
  2. Can people change their votes? Given that we’re asking significant questions here, what happens to people who have already voted and whose views may be swayed by the comments made here?
  3. How will people who haven’t voted when the voting period closes be counted? Clearly there are a number of people (myself included) who have strong opinions but don’t feel ready to vote yet. So treating them as having abstained seems wrong.

I’ll note that when I seconded the vote, I was really only agreeing to the idea that we handle voting via a github issue. I wasn’t saying “let’s go ahead right now”. And in particular, I don’t think that we’re ready to initiate the PEP 609 process of a week to vote, with a 2/3 majority on a simple yes/no question. I apologise for misunderstanding what you were asking for @pradyunsg. I’ll update my post seconding the proposal to make that clear, and add a new post in the same thread pointing to that update. If that means the current vote needs to be abandoned and restarted, then I apologise for the wasted effort.

1 Like