Draft update to Python Packaging Governance

Should it change? There is a council called PyPA which governs these tools. I feel there is no need for a change.

1 Like

We would want Python Packaging community to be much bigger than the projects that collaborate under the PyPA umbrella.

This seems to put a lot of burden on the council to correct any mistaken assumptions the community might make. I don’t think we should expect a 5-member council, who were quite likely elected based on criteria other than their marketing skills, to do this.

And it doesn’t address the situation where there is no recommended tool (e.g., workflow tools) for whatever reason - e.g., because there’s no clear consensus, or because the council chooses to allow for user choice.

1 Like

We decided to call the council as Python Packaging Authority so that there would be no distinction between a ‘Packaging Council’ and ‘Python Packaging Authority’. A user would not care about these semantics and I doubt they will have any assumptions about this council.

People have a lot of assumptions about the “Python Packaging Authority”. That’s precisely why I think the new council should have a different name, to allow people to start afresh without pre-existing assumptions. Agreed a user should not have to care about the details of packaging governance. But they should understand that the council is a fresh start, and a new name is (IMO) the best way of doing this cheaply (i.e., without a big publicity effort).


I do feel this is covered in the Scope section of the draft. I would prefer the PEP remain vague in terms of how the council would improve Python Packaging but one of the ways would be to improve communication between various stakeholders. I do not want to specify each way the council could improve Python Packaging as it would become restrictive.

I have to disagree. If the council approves PEPs but if projects do not implement them, then what is the point of the council? How is it different from what we have now? If the issue is additional resources, then the council can work with the project and the PSF to figure out a solution.

You’re right. I will update the wording.

I think that is the main point. But as I said, having the resources “available” is not enough, there is a need for actually finding/hiring/managing the people to implement that.

Just “wishing” implementation into existence is not going to solve the problem (at least not yet :sweat_smile:). The way the PEP is written seems to put a burden into the volunteer time that maintainers have available. And tbh using “elected authority” to pressure how maintainers prioritize the use of their volunteer time is not cool.

1 Like

They may not have marketing skills but I am sure they can communicate. If it is too much burden on the council, let them decide how to handle this issue.

I do not have any solution for this. The council has to decide how to deal with such situations.

Fair enough. I will wait until the end of this discussion to decide how this council should be called.

1 Like

I think the core thing isn’t that a project has to suddenly find resources to implement something, but that projects governed by the council can’t decide not to implement something because they disagree with it.


That is OK, but maybe the wording could be changed to differentiate between the 2 interpretations?

I think that this differentiation is important, because maintainers may agree with a PEP, but don’t have the time to implement it and/or find a different use of their volunteer time (e.g. something else they prioritise, or because the implementation is difficult or generally “not fun”).

Volunteer time should not be treated as a resource that can be steered into a direction in a top-down manner. That is not how it works, and a governance model for a packaging council has to take that into consideration. The choice of words is important in this case.

In the issue tracker of the PyPA projects we already see users trying to “intimidate”[1] maintainers into implementing stuff because a PEP is approved. The better approach for wanting to see something implemented is to actually provide a PR for it.

  1. With air quotes, for the lack of a better term. I will play my non-native speaker card here. Sorry for the misuse of the term. It is not my intention to offend anyone. ↩︎

1 Like

BTW, for the problem of building consensus, there is some interesting work in the literature about organisational structures that can (in theory) be applied to volunteer work. I can think at least on Sociocracy, but probably there are other ones.

It might be worth to have a look on such studies in the context of this proposal.

1 Like

This prompts a further question. Can a project withdraw from the PyPA (or whatever we call “the group of projects that are governed by the council”)? I can imagine a situation where I create a project (editables, for example) and ask for PyPA membership. But then the council says that all PyPA projects must follow some rule I disagree with (for example, they must all use the “official” toolchain). Can I withdraw editables from the PyPA? Or by becoming a PyPA project in the first place, did I give up my right to manage my own project how I want to?

I think the answer to that is probably yes, the PyPA now owns my project and I cannot choose to withdraw, or to not follow council rulings that I disagree with. Which for me is a strong disincentive to become a PyPA project (particularly as I still have to deal with all of the responsibilities of being a project owner).

There’s a question here of project management style. Some projects have a shared ownership model, where decisions are by consensus. Others are very much one person’s vision and as such, management by the council might not be what the project owner wants, and might not even be in the best interests of the project. And that could very well apply to existing PyPA projects, not just to projects considering membership.


PEP 609 defines processes for adding and removing PyPA projects.

Does this PEP supersede those parts? Does this PEP supersede other parts, or the whole of, PEP 609?

I think this is covered by https://peps.python.org/pep-0609/#leaving-pypa.

OK. I wasn’t sure (as @hugovk said) whether the existing governance still applied under the council. This new PEP needs to make that clear.

1 Like

docs.python.org is generated from the CPython repo, so there isn’t really a way to hand over jurisdiction outside of the core devs and to someone else (nor would the core devs probably want to do that).


Noted. I will make it clearer.

@smm @pf_moore I think you are both right here.
There’s a huge pool of Python users who are not on this Discourse who have little or no idea what the PyPA is. There’s also people who are very active on this Discourse, each of which has often conflicting ideas about what PyPA is or should be.

More importantly, as you well know, the whole point of setting up a council is to address issues with the current situation including the PyPA.

So shouldn’t you call it the “Python Packaging Council” to make it very explicit to all those people that this is like the core Python steering council, but for packaging, and not the PyPA? Just my two cents as a relative outsider.