This document describes a governance model for the Python PackagingAuthority (PyPA). The model is closely based on existing informalpractices, with the intent of providing clarity into the functioningof the PyPA and formalizing transparent processes for the PyPA.
The Python Packaging Authority (PyPA) is a collaborative communitythat maintains and advances many of the relevant projects in Pythonpackaging. The software and standards developed through the PyPA areused to package, share, and install Python software and to interactwith indexes of downloadable Python software such asPyPI, thePython Package Index.
Currently, the PyPA is an informal and loosely defined organizationthat lacks true authority, and the inclusion of a given project underthe PyPA umbrella or the creation of new projects has been done in anad-hoc, one-off manner. Similarly, individual membership in the PyPAis not well-defined.
While this model has more or less worked for the PyPA in the past, itresults in an organization which is missing certain features of astable ecosystem, namely a clear and transparent decision-makingprocess. This PEP seeks to rectify this by defining a governance modelfor the PyPA.
Relevant terms for groups of individual contributors used in this PEP:
The following section formalizes the goals (and non-goals) of the PyPAand 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 mosthave not been explicitly defined.
In the event that a given project needs additional support, or nolonger has active maintainers, the PyPA will ensure that the givenproject will continue to be supported for users to the extentnecessary.
The PyPA should, as much as possible, strive for standardization andcoordination across PyPA projects, primarily though the governanceprocess outlined below. PyPA projects are expected to abide byapplicable specifications maintained by the PyPA.
The PyPA community (especially PyPA members) should be expected toprovide opinions, insight and experience when ecosystem-wide changesare being proposed.
For example: accepting new projects from the community, organicallycreating projects within the PyPA, etc.
Generally this means leading by example, but occasionally it may meanmore 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 newmembers to their projects. Maintainership of a project that is underthe PyPA organization automatically transfers membership in the PyPA.
As long as the project is adhering to the Code of Conduct andfollowing specifications supported by the PyPA, the PyPA should onlyconcerned with large, ecosystem-wide changes.
PyPA projects followthe PSF Code of Conduct.
These are new goals which the governance model seeks to make possible.
Provide a transparent process for decisions taken, regarding projectmembership in the PyPA.
Formally document how the PyPA uses Python Enhancement Proposals(PEPs), for maintaining interoperability specifications defined by thePyPA.
The processes for the PyPA’s activities are outlined below:
The PyPA will use PEPs for defining, and making changes to, theinteroperability specifications maintained by the PyPA. Thus, thePython Steering Council has the final say in the acceptance of theseinteroperability specifications.
It is expected (but not required) that the Python Steering Councilwould delegate authority to sponsor and/or approve/reject PEPs relatedto packaging interoperability specifications, to individuals within thePyPA community. At the time of writing (June 2020), the Python SteeringCouncil hasstanding delegations for currently active packaginginteroperability specifications.
The details of the process of proposing and updating theinteroperability specifications are described in thePyPASpecifications document.
A PyPA member can put forward a proposal and call for a vote on apublic PyPA communication channel. A PyPA committer vote is triggeredwhen a PyPA committer (not the proposer) seconds the proposal.
The proposal will be put to a vote on thePyPA-Committers mailinglist, over a 7-day period. Each PyPA committer can vote once, and canchoose one of+1 and-1. If at least two thirds of recordedvotes are+1, then the vote succeeds.
PyPA committer votes are required for, and limited to, the followingkinds of proposals:
Proposing the acceptance of a project into the PyPA organization. Thisproposal must not be opposed by the existing maintainers of theproject.
Proposing the creation of a new tools / project in the PyPAorganization.
Proposing the removal of a project in the PyPA organization.
Proposing changes to how the PyPA operates, including but not limitedto changes to its specification and governance processes, and thisPEP.
A project that is a part of the PyPA organization, can request toleave PyPA.
Such requests can made by a committer of the project, on thePyPA-Committers mailing list and must clearly state the GitHubuser/organization to transfer the repository to.
If the request is not opposed by another committer of the same projectover a 7-day period, the project would leave the PyPA and betransferred out of the PyPA organization as per the request.
Each project that is a part of the PyPA organization followsthe PSFCode of Conduct, including its incident reporting guidelines andenforcement procedures.
PyPA members are responsible for leading by example. PyPA membersoccasionally may need to more explicitly moderate behavior in theirprojects, and each project that is a part of the PyPA organizationmust designate at least one PyPA member as available to contact incase of a Code of Conduct incident. If told of any Code of Conductincidents involving their projects, PyPA members are expected toreport those incidents up tothe PSF Conduct WG, for recordingpurposes and for potential assistance.
This document is placed in the public domain or under theCC0-1.0-Universal license, whichever is more permissive.
Source:https://github.com/python/peps/blob/main/peps/pep-0609.rst
Last modified:2025-02-01 08:55:40 GMT