On behalf of @pradyunsg and @brainwane, and myself, I'd like to submit PEP 609 -- PyPA Governance for consideration to the Steering Council.
PEP 609: Overview for Steering Council
Why does the PyPA want a formal governance model?
The PyPA started in 2011 as a loose confederation of developers, trying to create an alternative to the standard utilities. At that time, informal personal relationships were sufficient to help developers make decisions. Now that the PyPA maintains the canonical package repository and the official toolchain for uploading to it, downloading from it, as well as for creating, distributing, and installing Python packages. We need more systematic ways to make and enforce decisions. Examples:
- A new project asks for membership. Should we admit it, thus granting an imprimatur?
- An architectural decision will affect several PyPA projects. Whose approval is necessary? When have we reached consensus? When is the deadline to make that decision?
- Someone wants the PyPA to run differently. Who decides what is mandatory?
- There’s a new internship program that will help us get new contributors, but participating will increase our support load in the short run. Should we participate?
- A member of several PyPA projects is disruptive. Who has the power to remove their membership, and what is the procedure they should follow?
Right now, the answers to all of those questions are basically “There’s no real answer -- ask around, talk about what you want in the mailing lists and on Discourse, and eventually maybe a consensus will form” (with no certainty on how long that will take). This discourages new contributors, corporate participation, and large architectural projects, and slows the overall decision-making process.
Why does the PyPA currently have a BDFRN?
PyPA members in 2018 nominated Dustin Ingram as the Benevolent Dictator For Right Now (BDFRN), to document existing practices and bootstrap the PyPA into its first formal governance system. That culminated in creating this PEP. Acceptance of this PEP will dissolve the role of BDFRN.
What are the alternative models considered and their trade-offs?
Originally, the BDFRN proposed “The Lightweight Model”, a consensus-based governance using an RFC process, replacing the existing PEP process.
This model had the following goals:
- Provide support for existing projects under the PyPA
- Foster the creation and acceptance of standards for PyPA projects
- Guide decisions which affect multiple PyPA projects
- Accept new projects into the PyPA
- Enforce adherence to the CoC uniformly across all projects
PyPA members felt that adding a separate RFC process to replace PEPs was redundant, and that instead the existing PEP process could be adjusted to better suit the PyPA’s use of it.
Next, this proposal was updated to what was called “The Status-Quo Model”: same goals as above, but eliminating the proposed RFC process and instead using the existing PEP mechanisms. This model also adds voting for governance-related decisions based on PEP 13.
Finally, the model was updated to enforce the PSF Code of Conduct rather than the PyPA Code of Conduct after it was discussed.
This model is the final proposed governance model.
How would PyPA’s use of the PEP process be affected?
The PEP process is designed for and coupled to core development (e.g., a Core Dev needs to sponsor). This is increasingly incongruous as packaging development is fairly isolated from core development. Most PEPs about packaging do not concern core development, and vice versa.
Paul Ganssle wrote:
I think at the very least there needs to be a process by which PyPA members can be empowered to make these proposals without a sponsor: I am ambivalent as to whether that is automatic upon joining any PyPA project or whether there’s a slightly higher bar - but it cannot be as high as “is a core dev of CPython”.
Originally, the governance proposal outlined a new RFC process, similar to PEPs, but explicitly for Packaging standards, giving the PyPA more flexibility with who can propose standards and who can approve standards.
During discussion, it was expressed that a new RFC process would be mostly duplicative of the existing PEP process. As a result, we decided to ask for changes to the PEP process instead, to better suit the PyPA’s needs.
What changes would better accommodate the PyPA’s usage of the PEP process?
We have two main changes to suggest:
- Namespacing for PyPA-related PEPs. Make it easier for us to find, list, and refer to PEPs that are primarily of concern to Python packaging developers.
- Expand sponsorship eligibility. As mentioned above, the PyPA would like more flexibility regarding who can propose standards, The PyPA would determine a list of people allowed to sponsor PyPA-related PEPs. PEP 1 or the Standing Delegations list would need to be revised accordingly.
Why is the PyPA bringing this to the Steering Council for a decision?
The PyPA does not have authority to approve these changes. We’ve arrived at this model after years of discussion, and would like either to move forward with it, or an alternative way to achieve the goals listed above. This is not the end of the discussion; after the Steering Council decides on this PEP, ideally the PyPA and the Steering Council will continue to discuss and refine the scope of the PEP process, how and when it applies to packaging-specific standards and architecture decisions, and how we all might adapt governance processes further.
References: