286 lines
9.4 KiB
ReStructuredText
286 lines
9.4 KiB
ReStructuredText
PEP: 609
|
||
Title: PyPA Governance
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: Dustin Ingram <di@python.org>,
|
||
Pradyun Gedam <pradyunsg@gmail.com>
|
||
Sponsor: Paul Ganssle <paul@ganssle.io>
|
||
BDFL-Delegate: TBD
|
||
Discussions-To: https://discuss.python.org/t/pep-609-pypa-governance/
|
||
Status: Draft
|
||
Type: Process
|
||
Content-Type: text/x-rst
|
||
Created: 05-Nov-2019
|
||
Post-History: 05-Nov-2019
|
||
|
||
|
||
Abstract
|
||
========
|
||
|
||
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.
|
||
|
||
Rationale
|
||
=========
|
||
|
||
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.
|
||
|
||
Terminology
|
||
===========
|
||
|
||
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`_. For clarity: there is no
|
||
formal relationship between the Packaging-WG and PyPA. This group is
|
||
only included in this list to disambiguate it from PyPA.
|
||
|
||
Goals
|
||
=====
|
||
|
||
The following section formalizes the goals (and non-goals) of the PyPA
|
||
and this governance model.
|
||
|
||
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 a Code of Conduct 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
|
||
'''''''''''''''''''''''''''''''
|
||
|
||
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.
|
||
|
||
Develop and maintain standalone Code of Conduct
|
||
'''''''''''''''''''''''''''''''''''''''''''''''
|
||
|
||
PyPA projects follow `the PSF Code of Conduct`_.
|
||
|
||
|
||
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 the PyPA's activities are outlined below:
|
||
|
||
Specifications
|
||
--------------
|
||
|
||
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.
|
||
|
||
The details of the process of proposing and updating the
|
||
interoperability specifications are described in the `PyPA
|
||
Specifications`_ document.
|
||
|
||
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 the 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 the 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, and this
|
||
PEP.
|
||
|
||
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.
|
||
|
||
Code of Conduct enforcement
|
||
'''''''''''''''''''''''''''
|
||
|
||
Each project that is a part of the PyPA organization follows `the PSF
|
||
Code of Conduct`_, including its incident reporting guidelines and
|
||
enforcement procedures.
|
||
|
||
PyPA members are responsible for leading by example. PyPA members
|
||
occasionally may need to more explicitly moderate behavior in their
|
||
projects, and each project that is a part of the PyPA organization
|
||
must designate at least one PyPA member as available to contact in
|
||
case of a Code of Conduct incident. If told of any Code of Conduct
|
||
incidents involving their projects, PyPA members are expected to
|
||
report those incidents up to `the PSF Conduct WG`_, for recording
|
||
purposes and for potential assistance.
|
||
|
||
|
||
References
|
||
==========
|
||
|
||
.. _PyPI: https://pypi.org
|
||
.. _PyPA Organization: https://github.com/pypa
|
||
.. _PyPA Specifications: https://www.pypa.io/en/latest/specifications
|
||
.. _PyPA-Committers: https://mail.python.org/mm3/mailman3/lists/pypa-committers.python.org/
|
||
.. _Packaging-WG Wiki page: https://wiki.python.org/psf/PackagingWG
|
||
.. _standing delegations: https://github.com/python/steering-council/blob/master/process/standing-delegations.md#pypa-delegations
|
||
.. _the PSF Code of Conduct: https://www.python.org/psf/conduct/
|
||
.. _the PSF Conduct WG: https://wiki.python.org/psf/ConductWG/Charter
|
||
|
||
Copyright
|
||
=========
|
||
|
||
This document is placed in the public domain or under the
|
||
CC0-1.0-Universal license, whichever is more permissive.
|
||
|
||
|
||
|
||
..
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
sentence-end-double-space: t
|
||
fill-column: 70
|
||
coding: utf-8
|
||
End:
|