|Author:||Dustin Ingram <di at python.org>, Pradyun Gedam <pradyunsg at gmail.com>|
|Sponsor:||Paul Ganssle <paul at ganssle.io>|
- Goals of the PyPA
- Non-goals of the PyPA
- Goals of the PyPA's Governance Model
This document describes a governance model for the Python Packaging Authority (PyPA). The model is closely based on existing informal practices, with the intent of providing clarity into the functioning of the PyPA and formalizing transparent processes for the PyPA.
The Python Packaging Authority (PyPA) is a collaborative community that maintains and advances 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.
Currently, the PyPA is an informal and loosely defined organization that lacks true authority, and the inclusion of a given project under the PyPA umbrella or the creation of new projects has been done in an ad-hoc, one-off manner. Similarly, individual membership in the PyPA is not well-defined.
While this model has more or less worked for the PyPA in the past, it results in an organization which is missing certain features of a stable ecosystem, namely a clear and transparent decision-making process. This PEP seeks to rectify this by defining a governance model for the PyPA.
Relevant terms for groups of individual contributors used in this PEP:
- 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.
- PyPA community:
- Anyone who is interested in PyPA activity and wants to follow along, contribute or make proposals.
- Packaging-WG members:
- As described in the Packaging-WG Wiki page .
The following section formalizes the goals (and non-goals) of the PyPA and this governance model.
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.
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.
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.
The PyPA community (especially PyPA members) should be expected to provide opinions, insight and experience when ecosystem-wide changes are being proposed.
For example: accepting new projects from the community, organically creating projects within the PyPA, etc.
Generally this means leading by example, but occasionally it may mean more explicit moderation.
These are specific items that are explicitly _not_ goals of the PyPA.
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.
As long as the project is adhering to the Code of Conduct and following specifications supported by the PyPA, the PyPA should only concerned with large, ecosystem-wide changes.
These are new goals which the governance model seeks to make possible.
Provide a transparent process for decisions taken, regarding project membership in the PyPA.
Formally document how the PyPA uses Python Enhancement Proposals (PEPs), for maintaining interoperability specifications defined by the PyPA.
The processes for the PyPA's activities are outlined below:
The PyPA will use PEPs 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 (but not required) that the Python Steering Council delegates the authority to approve or reject PEPs to individuals within the PyPA community. At the time of writing (November 2019), the Python Steering Council has standing delegations  for currently active packaging interoperability specifications.
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:
Proposing the acceptance of a project into the PyPA organization. This proposal must not be opposed by the existing maintainers of the project.
Proposing the creation of a new tools / project in the PyPA organization.
Proposing the removal of a project in the PyPA organization.
Proposing changes to how the PyPA operates, including but not limited to changes to its specification and governance processes, and this PEP.
A project that is a part of the PyPA organization, can request to leave PyPA.
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.
|||(1, 2, 3) https://mail.python.org/mm3/mailman3/lists/pypa-committers.python.org/|
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.