Draft update to Python Packaging Governance

Certainly this is true. The question is whether the benefits of such decisions might outweigh those costs. Right now, it doesn’t matter how beneficial an unpopular decision might be in the long run, there’s no way forward.

I think it’s also a little misleading, because there is never a consensus over all the people affected. It’s only possible among the people who were able to participate in any given discussion. Of course those people are typically very well-informed and experienced, but there are always going to be others who will be pushed farther away by any given decision.

1 Like

I’m not even sure that “unpopular” is the right thing here, because we currently don’t have a mechanism even for popular decisions unless we can force them into a standards shape, because we don’t have a decision making process, so we sort of haphazardly fall back to unanimous consent, which means that generally even if almost everyone agrees with some change, one person whose willing to post a lot can more or less apply stop energy to prevent things from happening.

This was more or less exactly the situation we were in a decade ago [1], except it also applied to things that are now covered by the standards process.

My expectation is that whatever decision making process we come up with, will have some mechanism where it can weigh choices along the various axis like:

  • How do the projects involved feel about this change?
  • How do the users (to the extent that we can ask them) feel about this change?
  • How much benefit do we expect to gain from this change?
  • How much cost do we expect this change to incur?

Does this mean that in some cases we will effectively force some people into a change they don’t like? Yes, but that is already true today! None of our standards require unanimous consent, we just assume that the person making the decision is going to weigh things like the above questions and try to make a reasonable decision. I’m not aware of any large scale decision making process in the real world that both functions and requires 100% of the people involved to be “pro” some decision.

  1. I think it took us something like 8 months of arguing to get PyPI to be served over HTTPS with a TLS certificate that was trusted by default in all modern browsers. Even then, if my memory serves me correctly, we never actually got agreement that we should do that, the infrastructure team started to get built out more, and just did it unilaterally. ↩︎


That is always a good reflection. In general, groups first have to objectively define what it means to reach consensus (which is rarely “100% pro votes”, I agree). These diagrams summarise a bit what is the general understanding of consensus and how to achieve it (ref):

With some research and I found this interesting reference about the topic: Consensus Decision Making - Seeds for Change (they also have a handbook). The section on the process of consensus and the flowchart are very interesting, as well as the section on “Consensus in large groups” and the one about “Common Challenges”.

They mention as examples of organisations that use consensus-based decision making the Unicorn Grocery, Radical Routes, N Street Cohousing in California. There are some other examples in Consensus decision-making - Wikipedia, two very interesting regards the US Bureau of Land Management policies and the 2015 United Nations Climate Change Conference involving 195 countries.
Apparently Wikipedia itself recommends some form of “consensus-driven” mechanism for editors.

Another thing to consider is that we have more alternatives than just “consensus” vs. “elected council with power to impose decisions”.

The wikipedia article mentions the IETF rough consensus model (described in details in RFC 2418 - IETF Working Group Guidelines and Procedures, specially section 3). It is very interesting that
Section 3.3 of the IETF document mentions the challenge of gauging the level of consensus in mailing lists. We probably can directly relate to that experience and learn from them.

There also some forms of governance that “relax” the concept of consensus into consent (as in “good enough for now, safe enough to try” + “no reasonable and articulated valid objections”)[1]:


There are some sources in this approach in Sociocracy for all, Sociocracy 3.0 and https://www.sociocracy.info/. There are several case studies (ref1, ref2, ref3) for these forms of governance for companies, co-ops, non-profifts, etc… There is also an interesting text on asynchronous online collaboration using Trello.

Conclusion: There are examples around the world of organisations (even large ones) that perform decision making using a consensus-based process (or at least a “relaxed” form of it, e.g. by using “consent”).

What all these organisations have in common is a clear process (or at least as formalised as possible) on how to achieve consensus and deal with objections.

On a side note: My general impression is that these processes were initially designed to be “face-2-face first” (i.e., prioritise in-person meetings), which could be slightly challenging to adapt to PyPA but not impossible. Indeed, I mentioned[2] a few attempts to migrate to online and asynchronous platforms that we can learn from, and there is probably more out there[3].

  1. If we refer back to the first figure in the post, it seems that consent-based decision making expands the “Implement space”. ↩︎

  2. The IETF process and the " Sociocracy 3.0 with Trello" ↩︎

  3. I am sure that after the past years of pandemic there are more resources about online collaboration based on equity than ever before. And we can still do online meetings in which we can replicate to some extent the “face-2-face” methodology. ↩︎


There’s a lot of information here, and my time constraints means it’ll probably take me awhile to get through it all and I didn’t want to just leave this thread dangling, so I wanted to just explicitly acknowledge this, and also mention one higher level thought (without having read any of the links in your post to dig into them).

I’m not personally particularly married to any one specific mechanism for making decisions as long as whatever we end up with is a reasonable process that is able to actually make decisions (vs what we have now).

I think from a consensus decision making POV the council idea is “good enough”, because I think anyone we elect into that position is likely going to try and form rough consensus wherever possible anyways (just like our PEP-Delegates do already) so I’m not super worried about formalizing that need, but I recognize that others may feel differently! What I wonder (and this may exist in some of your links already, if so I apologize) is how these alternative systems handle non-binary choices.

For example, with PEP 722/723 I think we have a rough consensus (or consent at least) that we should do something for those problems, and that one of PEP 722/723 are a good enough for now thing to try. However when you have to pick between them, things feel pretty evenly split between the two options.

One thing I am worried about in this discussion is something I don’t quite have a word for it, but Brett mentioned it earlier. When we were discussing doing the elections for the Python Steering Council we spent quite a bit of time deep in the weeds of choosing various types of voting systems (majority? IRV? Approval? Star? etc). I was guilty of this myself even. In hindsight, I suspect we could have picked literally any voting system (including just having a PSF officer take votes in a google spreadsheet lol) and been just fine, and all that time spent arguing over the specifics of voting nerd shit was largely pointless [1].

In any case, I’m definitely going to read through those links as I can, but what I think might be helpful though is for folks who are concerned about the council thing, or would prefer a different solution, to lay out a different idea? It doesn’t need to be a PEP or anything at this point, just a quick summary or something would be great. Or if they think that we don’t need a higher level decision making process and the status quo is fine too, then that would be useful information to know.

  1. To be clear, I’m not calling your concerns here pointless, because I do think this is a more fundamental question than the one of “do we use IRV or Approval or What?”. I’m just worried that the practical differences between all reasonable solutions here are so low that it’s more important that we just pick one of them, than which particular one we actually pick. ↩︎


While this is a valid point, I’d like to bring things back to a more practical level. What specific issues are currently being caused by this lack of a decision making mechanism? In particular, how sure are we that “not having a decision” is the blocker, as opposed to “not having enough volunteer (or other) resource” or “having to deal with legacy data” or “contributor burnout” - the latter of which is likely caused by this sort of governance discussion, rather than being helped by it[1].

I’m not saying that “just muddle along ignoring the bigger picture” is the answer. Nor am I saying that there aren’t issues that a change in governance wouldn’t fix. But in terms of cost/benefit, we’ve collectively put a huge amount of volunteer resource into all these discussions. And so far, we’ve not delivered anything. And even if we do, whether it’s in the form of a council or something else, will it genuinely deliver enough value to justify the time spent?

  1. speaking from a personal POV, at least ↩︎


Off the top of my head, things that have been blocked or hampered by a lack of ability to make decisions like this:

  • Lock file support
    • From what I could tell, basically everyone agreed we should have a lock file, but were split on what exactly that lock file should entail.
  • PyBI (or similar proposals where the toolchain provides Python)
    • These proposals all generated a bunch of discussion, and then petered out when it was clear that we couldn’t get agreement on whether it was a good idea or not.
  • Any attempt at unifying the experience for end users.
    • This is by far the most common complaint that basically everyone not involved in packaging has with Python’s packaging, and every single thread on it has hundreds, sometimes > 1k, posts.
    • So far our only “solution” to something like this is “well people can just keep making the problem worse by coming up with more and more alternative tools, and maybe one of them will be good enough that people will just organically abandon everything else and we won’t have to make this decision”.
  • Any kind of official workflow tooling.
  • The pressure our solutions are putting on OSS maintainers to provide ever more wheels, and how we can stop doing that.
  • I suspect there’s more here too! I know personally I’ve avoided even bothering to raise topics in the past where I was pretty sure that we were going to get stuck in a quagmire and not go anywhere. But more generally, the process you have will constrain the possible changes that you can make, and people are naturally going to try and fit things to match that process rather than the real thing they want.

Let’s remember the survey that kicked off these discussions of “vision”, “strategy”, and “governance”. Particularly:

Now we’re all volunteers so we’re not bound to provide what our users want, but it’s pretty clear to me that the direction that the community wants packaging to go isn’t something we’re going to be able to get to without a change in decision making. The way we ended up accidentally is basically the exact opposite of what a clear super majority of people want, and I suspect people are going to continue to be unhappy until that is resolved.


Also I suspect that “not having a decision” also contributes to “not having enough volunteer resources” and “contributor burnout”. I know of at least one person who has experienced burn out due to discussions like the lock file discussions that went round and round without a decision.

It’s also harder to get people to volunteer their time when they have to start out with with a multi year discussion with a high chance of going nowhere if they want to make any sort of larger scale change.


That one’s on me, as PEP delegate. I rejected PEP 665 because I made the decision that sdist support was important, and that PEP didn’t cover it. So the lack of lock file support is because of a clear decision being made, not because we have no decision process.

Otherwise, I’ll acknowledge your points and move on.

But what I’m not clear on, are you in favour of, or against @smm’s draft PEP as it’s written? Because I feel that we’re debating the question of “having a decision making body” but ignoring the real point of this thread, which is to establish whether there’s community support for the proposed PEP.

I’m strongly against the PEP, largely over the “ownership” question, but also because I favour a “minimal” remit for the council which they expand at their own discretion. I’m a “block” in the sense of the consensus diagrams @abravalheri posted.

The discussion here has been about various principles, but I have very little sense of whether people are in favour of, or against, the draft PEP as written. Because that’s what will get submitted for the SC to decide on, and I think we need to provide a clear sense of whether the community support it as a whole.

1 Like

Thanks for these intriguing resources. I took a look at several of them (although I must admit I didn’t read the 228-page “Consensus Handbook” :slight_smile: ). There is certainly some food for thought there. I noted this remark (from one of the guides) with wry amusement:

This middle part of the discussion can feel quite messy – it can be hard to see the way forward when everyone is grappling with lots of ideas and different people’s needs. You may think you are coming to agreement and then a new factor comes up and you have to go back to exploring differences (as represented by the spikes in the diagram). Don’t lose heart!

So maybe there’s hope for us yet! :slight_smile:

A big question for me is, do you envision this consensus-reaching process happening within something like a Packaging Council, or within a larger but still fairly clearly demarcated group (e.g., committers on some set of packaging repos), or within some even larger and less clearly demarcated community (e.g., everyone participating in discussions on this forum)?

The ideas from those guides can be taken in different directions. One possibility is we can continue as we have been, but just try to implement some of these consensus-building strategies, i.e., no change in structure but only in practices. Another is that we form an official council but specify its powers and practices in terms of consensus (i.e., have the PEP say the council acts by consensus rather than majority vote). I’m not sure if you’re suggesting one of these options or something else.

That said, I do have some concerns about taking this approach. One is related to a couple things @dstufft said:

In other words, the PEP’s proposed model is similar to the current process in being already somewhat consensus-oriented, but that process has led us to the situation we are in now, which is not super great (although it is better than things used to be). This is also related to something mentioned in the Wikipedia article you linked to, which is the likelihood that consensus-driven decision-making tends to favor the status quo. If we believe the current situation is not good, then perhaps we don’t want to choose a process that makes it easy to stay there.

A related issue has to do with what I mentioned above, viz., who is in the group which reaches consensus, compared to who is in the group the decision affects. A lot of the consensus-building literature you cited (and similar stuff I’ve seen in the past) is more or less oriented towards internal organization of groups, in the sense that “decisions should be made by people who are fundamentally affected by them” (from this guide you linked to). However, insofar as we treat things like the survey as indicators of our problem, that problem affects users of Python, not authors of packaging tools. We will never be able to get consensus among all users of Python even if we wanted to, due to the vast and dispersed nature of that group. Hence it’s unclear to me that achieving consensus among tool authors will necessarily solve the problem for users (especially because of what I said in the previous paragraph).

A possible way out of this (which has come up before) is to retreat from the idea of even attempting to broker any agreement among a broad swath of tool authors, and simply try to create documentation that guides users to the best tools for their needs. If we do this, then there is no threat of “imposing” anything on anyone, except in the sense that a council might say “if your tool doesn’t do this, python.org will say it’s not recommended[1]”.

For myself, I guess I’m kind of at “stand aside” in terms of the diagrams, or maybe leaning toward “accept with reservations”. I don’t think the PEP is bad, but I’d prefer more clarity on what specifically the council is supposed to decide and how it’s supposed to implement its decisions.

One other meta-thought that I had in reading the consensus guides is that maybe there’s a way to come up with a process where something like a PEP would itself be the outgrowth of a consensus-building process. Currently a PEP is authored by one or a small number of people and then decided on with an up-or-down decision (modulo some small tweaks) by another individual. This can contribute to those PEP authors (and deciders) feeling a sense of obligation/burnout, or, from another perspective, to a sense that the PEPs “belong” to their authors; and (as we see with PEPs 722 and 723) it can also lead to situations in which PEPs compete head-to-head, which is (for better or worse) quite antithetical to a consensus-oriented model. An alternative in which the PEP-esque document is more collaboratively constructed (and/or approved) could distribute those duties and attachments across a wider group. :slight_smile: On the other hand, some may be leery of “design by committee” (and I have some such reservations myself).

Whether that would be better than the draft PEP I’m not even sure myself. I’ll just note in this vein that I found @pradyunsg’s “vote for your Python governance dreams” thread refreshing. Although it’s “voting” it’s clearly more of an opinion-gathering thing than an up-or-down decision vote, and could be the base for sculpting a consensus. I also was aiming for something similar when I started the thread asking for 10+ year views on packaging.

  1. possibly only for a particular type of user ↩︎

I think those principles are helping clarify whether people are for or against the PEP.

I’m personally fine with the PEP, but I’m not hearing consensus around it. My feeling is that people are generally in favour of:

  1. Council of N people (3 or 5)
  2. pypa-committers are the initial voting roll
  3. The council decides on PEPs
  4. The council “owns” packaging.python.org (as I think that flows from being charge of the PEPs and thus the specs)

That suggests people are against the PEP in general as written. Are we at a point where we ask @smm to update her PEP or draft a new one?

  1. Council of N people (3 or 5)
  2. pypa-committers are the initial voting roll
  3. The council decides on PEPs
  4. The council “owns” packaging.python.org (as I think that flows from being charge of the PEPs and thus the specs)

This looks like a reasonable summary of what the rough consensus is. I think that moving this forward to an update of the PEP makes good sense. The points that you outlined @brettcannon provide a reasonable scope for Year 1 of the governance effort. I would lean toward 5 person council since it builds in a bit more balance of the work.

At the Core Dev Sprint, @guido pointed out the typing governance PEP to me. It’s well done and may provide some guidance for the packaging PEP structure.


Noted. I will update the PEP and take a look at the typing governance PEP too.

1 Like

@smm Is there progress on this update? I’m quite curious to see the revised version :slight_smile:

1 Like

@smm Ping?

No, I haven’t made much progress. I expect to share the updated draft towards the end of next week.

1 Like

The third version of the draft PEP is available below. I have removed most powers and narrowed down the mandate. The sections under elections are still the same as I haven’t seen any objections to those sections. Do let me know if I should change the powers/mandate even further.

PEP: 9999
Title: Python Packaging Governance
Author: Shamika Mohanan
Status: Draft
Type: Process
Topic: Governance
Content-Type: text/x-rst

This PEP describes the Python Packaging Governance for 
all tools that are included as part of the PyPA. The Packaging 
Council will approve PEPs related to all PyPA tools, 
represent the community that supports these tools 
and act as a representative of PyPA tools. 

From here on, this Packaging council will be called the 
Python Packaging Authority (PyPA). This PEP will supersede 
[PEP 609](https://peps.python.org/pep-0609/) 
and will cover all aspects of Python Packaging Governance.

One issue facing Python Packaging is that there is a lack of a 
comprehensive vision and strategy for Python Packaging tools. While 
`PEP 609 <https://peps.python.org/pep-0609/>`_
formalized the governance of tools included under the PyPA 
umbrella, this governance does not extend to setting long-term goals 
for PyPA tools. In order to ensure PyPA tools remain relevant in the 
future and cater to user requirements, it is important to set a vision 
and strategy for Python Packaging and PyPA tools. It is hoped that 
in the long-term, the council will focus on the Packaging ecosystem, 
define the vision and work with the community to develop the strategy. 
Attempts at defining the vision and strategy have failed so far.

The main motivation for this PEP is to create a body with the necessary 
powers to define the short-term and long-term goals for Python Packaging 
and to support the community in setting the strategy to 
achieve the goals. This governing body will represent PyPA tools 
when working with any other tool or group. 

As such, the mission of the initial council will be-

* Approving Python Packaging PEPs

We can expect the initial council to pick up a few problems 
outside of this list that they feel is important to the community. 
With each council, this mission will change depending on 
pressing issues and how the vision and strategy has changed.

The mandate and powers of the PyPA have been drawn up such that they 
are not too restrictive. Certain issues such as authority over maintenance 
and improvement of installers, build backends, Warehouse, and other PyPA 
software are not in the scope of the initial council. This could be added 
the future if all stakeholders agree to this change. It is expected that 
the mandate of powers of the council will grow as long as it can show that 
it is working in the best interest of the Packaging community. This 
council will be accountable to the Python Steering Council.


Python Packaging Authority


The packaging council will consist of 5 members.


The packaging council will-

* Support, encourage and facilitate the maintenance and improvement 
  of the quality of all PyPA tools
* Represent PyPA tools as a group when working with non-PyPA tools, 
  PSF, Python Steering Council and third-party entities such as operating 
  system package managers. The council will start discussions and engage 
  with stakeholders and the Packaging community and represent the 
  PyPA interests.
* Arbitrate on any packaging related issue brought to the council. This 
  should be done as the final resort.
* Improve diversity of the Packaging community. The council should work 
  with the PSF to introduce programmes aimed at 
  improving diversity of contributors.


Packaging Governance

* Accept or reject PEPs within the scope 
  delegated by the Python Steering Council
* Delegate parts of their authority to other subcommittees or processes

Packaging Assets

* Authority over `packaging.python.org <https://packaging.python.org/en/latest/>`_
* Maintain advisory role for any issue related to packaging docs

Stakeholder Management

* Act as a liaison with any packaging-related Python or non Python 
  technical group when specific tool representation is not appropriate. 
  For example, any group representing supply chain security. 
* Act as a liaison with the PSF and the Packaging Working Group to obtain 
  funding and any other areas of shared interest
* Act as liaison with the Python Steering Council

Packaging ecosystem and community

* Recommend projects for adoption into PyPA by vote. 
  External projects can self-nominate to be included under the PyPA umbrella.
* Expel PyPA project/individual

Scope: It is expected that the Packaging council will consider the Python Packaging 
ecosystem holistically and improve all aspects of Python Packaging rather than just 
one project. This includes any tool and workflow related to the PyPA and PyPI. The 
council should work towards improving user experience of all packaging tools under 
its purview and this might include deprecating certain tools and developing new tools 
depending on requirements. While it does not have any authority over non-PyPA tools, 
it is expected that the council makes decisions that benefit the entire Python Packaging 
ecosystem. This scope includes all aspects of packaging and distribution. It is expected 
the council will work on long-term goals such as improving interoperability with non-PyPA 
packaging tools and improving packaging UX.

To use its powers, the council votes. Every council member must either 
vote or explicitly abstain. Members with conflicts of interest on a particular vote 
must abstain. Passing requires a strict majority of non-abstaining council members.


Packaging Voting Body: The Packaging Voting Body (PVB) includes the following:

* PyPA committers
* Affiliate project voters

PyPA committers can nominate either non-PyPA projects or individual contributors 
who do not contribute to a PyPA project to be added to the PVB. These voters will 
be called affiliate project voters.

* Any voter nomination has to be seconded by another PyPA committer
* External projects nominated by PyPA committers will get to appoint a representative 
  for each ballot

The initial seed of voters will include all committers for the existing non-archived 
public projects under the `pypa` organisation of GitHub.

The PyPA has to maintain a list of eligible voters and their project affiliation. This 
list should contain the names of PyPA committers and affiliate project voters. 
This canonical list should be maintained by the PyPA with access available to 
all Packaging Voting Body members. This list should not share personal 
information publicly. It is the responsibility of all PyPA projects to 
ensure that the names of any new committers are added to the list of eligible voters 
and any communication spaces for the PyPA.

For the initial election, this voter list will be maintained by the PSF. 
Adding any new voters and subsequent due diligence is the responsibility 
of PyPA committers. Once the new council has been elected, ownership of the 
Packaging Voting Body membership list and the PyPA-voters mailing list will 
be transferred to the PyPA.

PyPA elections will be held in three phases

* Phase 1: Packaging voting body members nominate affiliate project voters. 
  Affiliate project voters are added to the list of eligible voters.
* Phase 2: Candidates advertise their interest in serving. Candidates must be 
  nominated by a PyPA voting body member. Self-nominations are allowed. 
  Candidates need not be a PyPA committer.
* Phase 3: Each PyPA voting body member can vote for zero or more of the candidates. 
  Voting is performed anonymously. Candidates are ranked by the total number of votes 
  they receive. If a tie occurs, it may be resolved by mutual agreement among the candidates, 
  or else the winner will be chosen at random.

Each phase lasts one to two weeks, at the outgoing council’s discretion. For the 
initial election, all three phases will last two weeks. The election for all 
subsequent councils will start in the 12th month since the previous council election.
The election process is managed by a returns officer nominated by the outgoing 
Packaging council. For the initial election, the returns officer will be nominated 
by the PSF Executive Director.

The council should ideally reflect the diversity of Python Packaging contributors 
and users. PVB members are encouraged to vote accordingly.


A new council is elected once every year. Each council’s term runs from 
when their election results are finalized until the next council’s term 
starts. There are no term limits. Generally, each council member’s term 
should last 12 months with one exception described below.


Council members may resign their position at any time. There could also be 
situations that council members have been removed from the council via a 
vote of no confidence. 

Whenever there is a vacancy during the regular council term, the council 
may vote to appoint a replacement to serve out the rest of the term. In 
such a situation, this council seat will be up for election at the next 
council election as long as the replacement has served 12 weeks or longer 
in the council. Therefore, the longest term for any council member will be 
15 months before that seat is up for election.

If a council member drops out of touch and cannot be contacted for a month or 
longer without prior notice, then the rest of the council may vote to replace them.

Conflicts of interest

In order to avoid any appearance of conflict of interest, at most 
2 members of the council can work for any single employer.
In a council election, if 3 of the top 5 vote-getters work for the same 
employer, then whichever of them ranked lowest is disqualified and the 
6th-ranking candidate moves up into 5th place; this is repeated until 
a valid council is formed.

During a council term, if changing circumstances cause this rule to be 
broken (for instance, due to a council member changing employment), then 
one or more council members must resign to remedy the issue, and the resulting 
vacancies can then be filled as described above.

Ejecting PyPA committer

The Packaging Council or PyPA member may initiate a vote to 
eject a member from the PyPA committer body. A council member 
or PyPA committer can put forward a proposal and call for a vote 
on a public PyPA communication channel. A PyPA committer vote 
is triggered when a PyPA committer (not the proposer) seconds 
the proposal.

The proposal will be put to a vote on the 
`PyPA-Committers <https://mail.python.org/mm3/mailman3/lists/pypa-committers.python.org/>`_ 
mailing list, over a 7-day period. Each PyPA committer and council member 
can vote once, and can choose one of +1 and -1. If at least two 
thirds of recorded votes are +1, then the vote succeeds.

Ejecting PyPA project

The Packaging Council or PyPA member may initiate a vote to eject 
a project from the PyPA. A council member or PyPA member can put 
forward a proposal and call for a vote on a public PyPA communication 
channel. A PyPA committer vote is triggered when a PyPA committer 
(not the proposer) seconds the proposal.

The proposal will be put to a vote over a 7-day period. Each PyPA 
committer and council member can vote once, and can choose one of +1 and -1. 
If at least two thirds of recorded votes are +1, then the vote succeeds.

A project can also choose to leave the PyPA. If a project is leaving the 
PyPA or has been ejected from the PyPA, it is the responsibility of the council 
to support the transfer of the GitHub repository out of PyPA to a personal repository.

Ejecting an affiliate project voter

Any Packaging Voting Body member or council member may initiate 
a vote to eject an affiliate voter from the Packaging Voting Body. 
A council member or PyPA committer can put forward a proposal and call 
for a vote on a public PyPA communication channel. A PyPA committer vote 
is triggered when a PyPA committer (not the proposer) seconds the proposal.

The proposal will be put to a vote on the PyPA-voters mailing list, over 
a 7-day period. Each PyPA voting body member can vote once, and can choose 
one of +1 and -1. If at least two thirds of recorded votes are +1, then the 
vote succeeds.

Vote of no confidence

Any PVB member or Packaging Council member can publicly call 
for one or more Packaging Council members to be removed from the Council 
via a vote of no confidence. 

The vote of no confidence should be called on a project communication 
channel and should be seconded by another PVB member.
The vote lasts for two weeks. PVB members can vote for or against the 
removal. If at least two thirds of voters express a lack of confidence, then 
the vote succeeds.

If the vote of no confidence is for a single member, the council member is 
removed from the council and the vacancy is filled as described above. If 
the vote is for the entire council, the council is dissolved and a new election is held.

PyPA committer


Similar to the Python core team, the PyPA committers is a group 
of volunteers who maintain and support PyPA tools. They have 
authority over the Python Packaging infrastructure, the Python 
Packaging GitHub organization and repositories, the bug tracker, 
the mailing lists, IRC channels, etc.


PyPA committers may participate in formal votes, 
typically to nominate new PyPA projects, 
and to elect the Packaging council.


Any Packaging project can request PyPA membership. 

A PyPA member can put forward a proposal to add a project 
to the PyPA and call for a vote on a public PyPA communication channel. 
This proposal must not be opposed by the existing maintainers of the 
project. A PyPA committer vote is triggered when a PyPA committer 
(not the proposer) seconds the proposal.

The proposal will be put to a vote on the PyPA-Committers mailing list, 
over a 7-day period. Each PyPA committer can vote once, and can choose 
one of +1 and -1. If at least two thirds of recorded votes are +1, 
then the vote succeeds.

Once a project has been added to the PyPA organization, the project 
falls under the purview of the PyPA and will be required to meet the 
guidelines as set by the PyPA.

As Packaging contribution requires support and time, it is the 
responsibility of the Packaging Council to ensure there are sufficient 
support mechanisms in the form of (but not limited to) mentorship, internship 
and fellowship to support and guide new PyPA contributors. The Packaging Council 
may work with the PSF to establish such programmes.

This PEP is based on `PEP 13 <https://peps.python.org/pep-0013/>`_ 
which in turn is based on a Django governance 
document authored by Aymeric Augustin.

Rendered version 3: https://github.com/hugovk/peps/blob/patch-1/pep-9999.rst

Diff from version 2 (post #90): Python Packaging Governance: Update to "Post #123" by hugovk · Pull Request #1 · s-mm/peps · GitHub


Thanks for the update! A quick read suggests it LGTM.

The one part of the proposal that I don’t think makes sense is to blur the terminology that distinguishes the clearly defined Packaging Council from the broader more loosely defined PyPA collective.

The proposed Council isn’t the PyPA, it represents the PyPA when such representation is needed, just as the SC aren’t the entire Python core development community, but they do represent it.

On that topic, something that the PEP should mention is the potential impact of the proposal on the current PSF Python Packaging Working Group (as once the Council exists, the rationale for the current Working Group structure gets substantially weaker). I don’t think the PEP needs to resolve that question, but I do think it needs to say something like:

"In the event that this PEP is accepted and an initial Python Packaging Council elected, then motions will be placed before both the existing PSF Python Packaging Working Group and the newly elected Python Packaging Council that address the future handling of the responsibilities of the Packaging Working Group listed at https://wiki.python.org/psf/PackagingWG/Charter

The exact contents of those motions will be a topic of discussion between the Working Group and Council members (along with PSF staff), rather than needing to be worked out prior to the Council election."

Maybe we dissolve the Working Group and the PSF consults with the elected Council directly (ala the way the main SC works), or maybe we make the elected Council automatic members of the WG, or maybe we change the WG selection process to be via Council nomination, or maybe we come up with another idea. Regardless, I think the PEP should commit to having that discussion, so prospective Council members don’t get surprised when the topic comes up in the future.


What are the next steps here?