Draft update to Python Packaging Governance

[smm (Shamika)]

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

[smm (Shamika)]

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

[pf_moore (Paul Moore)]

@smm

It is up to the council to communicate these recommendations to mitigate any assumptions that might be made about PyPA tools.

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.

[smm (Shamika)]

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.

[pf_moore (Paul Moore)]

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).

[smm (Shamika)]

@BrenBarn

The goal of the council would basically be to facilitate communication among users, tool authors, documentation authors, and standards authors, to make the work of all those groups more mutually beneficial.

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.

[smm (Shamika)]

@abravalheri

If the whoever “requires” is willing to put the effort necessary into PRs, that is fine. Otherwise “requiring” an implementation to be done by other people, sounds a bit too much.

Note also that “having funds available” for a work to be done, is not a solution either. GitHub - psf/fundable-packaging-improvements: Packaging improvements that could be funded has been curating a list of fundable improvements for a long time, but without someone actively looking to “hire” people, the tasks rarely get done.

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.

@abravalheri

This seems to indicate that there needs to be a vote for new committers to be introduced into a project. Is this interpretation correct?

You’re right. I will update the wording.

[abravalheri (Anderson Bravalheri)]

@smm

If the issue is additional resources, then the council can work with the project and the PSF to figure out a solution.

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 ). 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.

[smm (Shamika)]

@pf_moore

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.

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.

@pf_moore

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.

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

[smm (Shamika)]

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

[dstufft (Donald Stufft)]

@abravalheri

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 ). 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.

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.

[abravalheri (Anderson Bravalheri)]

@dstufft

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. ↩︎

[abravalheri (Anderson Bravalheri)]

@dstufft

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.

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.

[pf_moore (Paul Moore)]

@dstufft

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.

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.

[hugovk (Hugo van Kemenade)]

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?

[dustin (Dustin Ingram)]

@pf_moore

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 this is covered by https://peps.python.org/pep-0609/#leaving-pypa.

[pf_moore (Paul Moore)]

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.

[brettcannon]

@BrenBarn

In my view, the important thing is the documentation on docs.python.org, because, well, that is the Python documentation, and my read on the situation is that people see packaging as part of Python and want Python to improve its packaging (as opposed to seeing “Python packaging” as some separate entity). So I’d either like to see the council get clear jurisdiction over packaging docs on docs.python.org,

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).

@BrenBarn

have docs.python.org explicitly outsource all packaging docs to packaging.python.org.

Drop the "Distributing Python Modules" section of the docs

[smm (Shamika)]

Noted. I will make it clearer.

[nicholdav (David Nicholson)]

@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.