PyPA Status-Quo Governance Model

pypa_governance.md

PyPA Status-Quo Governance Model

Abstract

This document describes a proposed governance model for the Python Packaging Authority (PyPA). The model is closely based on existing informal practices, "status-quo", with the intent of providing clarity into the functioning of the PyPA and formalizing transparent processes for the PyPA.

Terminology

PyPA members

Anyone with the triage bit or commit bit, on at least one project in the PyPA organization.

PyPA committers

Anyone with the commit bit on at least one project in the PyPA organization, which should correspond to everyone on the PyPA-Committers mailing list.

Note that all PyPA committers are PyPA members.

PyPA community

Essentially anyone who is interested in PyPA activity and wants to follow along or make proposals.

Packaging-WG members

As described in the Packaging-WG Wiki page.

Goals

The Python Packaging Authority (PyPA) is a collaborative community that maintains many of the relevant projects in Python packaging. The software and standards developed through the PyPA are used to package, share, and install Python software and to interact with indexes of downloadable Python software such as PyPI, the Python Package Index.

Goals of the PyPA

These goals are the primary motivation for the existence of the PyPA. These goals are largely already being carried out, even though most have not been explicitly defined.

Provide support for existing projects under the PyPA

In the event that a given project needs additional support, or no longer has active maintainers, the PyPA will ensure that the given project will continue to be supported for users to the extent necessary.

Foster the creation and acceptance of standards for PyPA projects

The PyPA should, as much as possible, strive for standardization and coordination across PyPA projects, primarily though the governance process outlined below. PyPA projects are expected to abide by applicable specifications maintained by the PyPA.

Guide decisions which affect multiple PyPA projects

The PyPA community (especially PyPA members) should be expected to provide opinions, insight and experience when ecosystem-wide changes are being proposed.

Determine which projects should be under the guidance of the PyPA

For example: accepting new projects from the community, organically creating projects within the PyPA, etc.

Enforce adherence to the CoC uniformly across all projects

Generally this means leading by example, but occasionally it may mean more explicit moderation.

Non-goals of the PyPA

These are specific items that are explicitly not goals of the PyPA.

Determine who is and isn't a PyPA member

This is for members of individual projects to decide, as they add new members to their projects. Maintainership of a project that is under the PyPA organization automatically transfers membership in the PyPA.

Micromanage individual projects development

As long as the project is adhering to the Code of Conduct, the PyPA should only concerned with large, ecosystem-wide changes.

Goals of the PyPA's Governance Model

These are new goals which the governance model seeks to make possible.

Transparency in PyPA membership

Provide a transparent process for decisions taken, regarding project membership in the PyPA.

Document PyPA's use of PEPs

Formally document how the PyPA uses Python Enhancement Proposals (PEPs), for maintaining interoperability specifications defined by the PyPA.

Processes

The processes for PyPA's functioning are outlined below:

Specifications

PEPs will be used for defining, and making changes to, the interoperability specifications maintained by the PyPA. Thus, the Python Steering Council has the final say in the acceptance of these interoperability specifications.

It is expected (and not required) that the Python Steering Council would delegate the authority to approve (or reject) PEPs, to individuals within the PyPA community. At the time of writing (Sept 2019), the Python Steering Council has standing delegations for currently active packaging interoperability specifications.

The details of the process of proposing and updating the interoperability specifications are described at https://www.pypa.io/en/latest/specifications.

Governance

PyPA Committer Votes

A 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 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 voters vote +1, then the vote succeeds.

PyPA committer votes are required for, and limited to, the following kinds of proposals:

Addition of a project to PyPA

Proposing the acceptance of a project into the PyPA organization. This proposal must not be opposed by the existing maintainers of the project.

Creation of a new project in PyPA

Proposing the creation of a new tools / project in the PyPA organization.

Removal of a project from PyPA

Proposing the removal of a project in the PyPA organization.

Updates to the Governance/Specification Processes

Proposing changes to how the PyPA operates, including but not limited to changes to its specification and governance processes.

Leaving PyPA

A project that is a part of the PyPA organization, can request to leave PyPA.

Such requests can made by a committer of the project, on the PyPA-Committers mailing list and must clearly state the GitHub user/organization to transfer the repository to.

If the request is not opposed by another committer of the same project over a 7 day period, the project would leave the PyPA and be transferred out of the PyPA organization as per the request.

It is expected (and not required) that the Python Steering Council would delegate the authority to approve (or reject) PEPs, to individuals within the PyPA community.

Guido assigned BDFL-delegate responsibility to myself and @dstufft (interop and warehouse respectively) in the past. Is this statement intended to suggest that we ask the SC to ratify and/or modify those delegations, or are we expecting to simply assume they carry on unless the SC chooses to request a change? It's probably worth being explicit here (and I doubt there's any harm in requesting ratification, at least).

What I'm trying to say there is the Steering Council can operate as they want, and the PyPA expects that they'll delegate the relevant authority to PyPA folks, via mechanisms that they see fit.

We already have this delegation from the steering council, in the form of standing delegations to @pfmoore and @dstufft.

https://github.com/python/steering-council/blob/master/process/standing-delegations.md#pypa-delegations

That said, if you'd like additional clarity, I'll be happy to accept a suggestion for different wording here. :)

I wasn't aware of that standing delegations document. Thanks for the link.

A couple quick comments:

It seems like it would be good for the "Goals" section to be centered on something concrete and external to the PyPA. Right now it seems a bit circular because it talks about things like supporting PyPA projects and deciding what should be a PyPA project, but never saying what these projects all have in common (aside from being PyPA projects) and in particular why they are PyPA projects.

Maybe this could be handled by having a higher-level mission statement that talks e.g. about maintaining and furthering packaging for Python (and whatever other concrete things there are), and then the goals can reference back to the mission statement. Basically, it should answer the question of what is the underlying purpose of PyPA?

and can choose one of +1, +0 and -1.

It seems like you'd also want -0 (as well as 0 if someone is truly neutral) for completeness.

Thanks for this write-up Pradyun! More clearly documenting the status quo will provide a solid foundation for discussion in the future, if folks want to tidy up or clarify various aspects.

A few specific points:

• "working group" has a specific meaning in the PSF bylaws, so I'd avoid the phrase "PyPA is a working group". While it's an aspirational ideal we don't always attain, "PyPA is a collaborative community ..." would fit well there.
• I'd link directly to the Steering Council standing delegation document in addition to linking to the page on pypa.io (as per Paul's request for clarification above)
• In addition to encouraging member projects to abide by a common Code of Conduct, the PyPA also encourages (and aims to help enable) member projects to abide by applicable technical interoperability specifications once those have been defined. The non-goal section currently gives the impression that isn't necessarily the case
• As a description of the status quo, this governance write-up isn't really about adopting the PEP process - rather, it's about clarifying how the PEP process is used by PyPA (since we don't use PEP 1 as is - we use the process on pypa.io, which supplements PEP 1 with some additional PyPA-specific bits)

Thanks for the inputs @ncoghlan!

"working group" has a specific meaning in the PSF bylaws, so I'd avoid the phrase "PyPA is a working group".

Amended. We should also change that on pypa.io. :)

link directly to the Steering Council standing delegation document

Added a sentence stating that this is in effect, "at the time of writing".

the PyPA also encourages (and aims to help enable) member projects to abide by applicable technical interoperability specifications once those have been defined.

Added a sentence to the goal discussing standards.

this governance write-up isn't really about adopting the PEP process - rather, it's about clarifying how the PEP process is used by PyPA

Yea... I couldn't find a good way to phrase that when I was writing this. I tried again, dropping the word "process" and just saying that PyPA would use PEPs. Lemme know if you think this looks OK now. :)

@pradyunsg Aye, those updates addressed the bits I had questions about. Thanks!