iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 1: Update for governance changes related to the steering council (#896)

This commit is contained in:
Nick Coghlan 2019-02-21 10:50:18 +10:00 committed by Brett Cannon
parent 9c2fbbd245
commit 83687f6ee3
1 changed files with 106 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

154
pep-0001.txt
View File

@ -29,6 +29,19 @@ repository, their revision history is the historical record of the
feature proposal [1]_.
PEP Audience
============
The typical primary audience for PEPs are the core developers of the CPython
reference interpreter and their elected Steering Council, as well as developers
of other implementations of the Python language specification.
However, other parts of the Python community may also choose to use the process
(particularly for Informational PEPs) to document expected API conventions and
to manage complex design coordination problems that require collaboration across
multiple projects.
PEP Types
=========
@ -62,16 +75,30 @@ There are three kinds of PEP:
PEP Workflow
============
Python's Steering Council
-------------------------
There are several references in this PEP to the "Steering Council" or "Council".
This refers to the current members of the elected Steering Council described
in PEP 13 [5]_, in their role as the final authorities on whether or not PEPs
will be accepted or rejected.
Python's Core Developers
------------------------
There are several references in this PEP to "core developers". This refers to
the currently active Python core team members described in PEP 13 [5]_.
Python's BDFL
-------------
There are several references in this PEP to the "BDFL". This acronym stands
for "Benevolent Dictator for Life" and refers to Guido van Rossum, the
original creator of, and the final design authority for, the Python
programming language. (**Note:** since Guido's withdrawal as BDFL,
this position is vacant. See PEP 8000 for how the community plans to
fill the vacancy.)
This PEP still uses the title "BDFL-Delegate" for PEP decision makers. This is
a historical reference to Python's previous governance model, where all design
authority ultimately derived from Guido van Rossum, the original creator of the
Python programming language. By contrast, the Steering Council's design
authority derives from their election by the currently active core developers.
PEP Editors
@ -185,11 +212,11 @@ Once the review process is complete, and the PEP editors approve it (note that
this is *not* the same as accepting your PEP!), they will squash commit your
pull request onto master.
The PEP editors will not unreasonably deny a PEP. Reasons for denying PEP
status include duplication of effort, being technically unsound, not providing
proper motivation or addressing backwards compatibility, or not in keeping
with the Python philosophy. The BDFL can be consulted during the approval
phase, and is the final arbiter of the draft's PEP-ability.
The PEP editors will not unreasonably deny publication of a PEP. Reasons for
denying PEP status include duplication of effort, being technically unsound,
not providing proper motivation or addressing backwards compatibility, or not
in keeping with the Python philosophy. The Steering Council can be consulted
during the approval phase, and are the final arbiter of a draft's PEP-ability.
Developers with git push privileges for the `PEP repository`_ may claim PEP
numbers directly by creating and committing a new PEP. When doing so, the
@ -229,45 +256,71 @@ PEP Review & Resolution
-----------------------
Once the authors have completed a PEP, they may request a review for
style and consistency from the PEP editors. However, the content and
final acceptance of the PEP must be requested of the BDFL, usually via
an email to the python-dev mailing list. PEPs are reviewed by the
BDFL and his chosen consultants, who may accept or reject a PEP or
send it back to the author(s) for revision. For a PEP that is
predetermined to be acceptable (e.g., it is an obvious win as-is
and/or its implementation has already been checked in) the BDFL may
also initiate a PEP review, first notifying the PEP author(s) and
giving them a chance to make revisions.
style and consistency from the PEP editors.
The final authority for PEP approval is the BDFL. However, whenever a new
PEP is put forward, any core developer that believes they are suitably
However, content review and final acceptance of the PEP must be requested of the
core developers, usually via an email to the python-dev mailing list.
To expedite the process in selected cases (e.g. when a change is clearly
beneficial and ready to be accepted, but the PEP hasn't been formally submitted
for review yet), the Steering Council may also initiate a PEP review, first
notifying the PEP author(s) and giving them a chance to make revisions.
The final authority for PEP approval is the Steering Council. However, whenever
a new PEP is put forward, any core developer that believes they are suitably
experienced to make the final decision on that PEP may offer to serve as
the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination
is accepted by the other core developers and the BDFL, then they will have
the authority to approve (or reject) that PEP. This process happens most
frequently with PEPs where the BDFL has granted in principle approval for
*something* to be done, but there are details that need to be worked out
before the PEP can be accepted.
the BDFL-Delegate for that PEP, and they will then have the authority to approve
(or reject) that PEP. Individuals taking on this responsibility are free to seek
additional guidance from the Steering Council at any time, and are also expected
to take the advice and perspectives of other core developers into account.
If the final decision on a PEP is to be made by a delegate rather than
directly by the BDFL, this will be recorded by including the
"BDFL-Delegate" header in the PEP.
The designated decision maker for each PEP is recorded in the "BDFL-Delegate"
header in the PEP.
PEP review and resolution may also occur on a list other than python-dev
(for example, distutils-sig for packaging related PEPs that don't
immediately affect the standard library). In this case, the "Discussions-To"
heading in the PEP will identify the appropriate alternative list where
discussion, review and pronouncement on the PEP will occur.
Such self-nominations are accepted by default, but may be explicitly declined by
the Steering Council. Possible reasons for the Steering Council declining a
self-nomination as BDFL-Delegate include, but are not limited to, perceptions of
a potential conflict of interest (e.g. working for the same organisation as the
PEP submitter), or simply considering another potential BDFL-Delegate to be
more appropriate. If core developers (or other community members) have concerns
regarding the suitability of a BDFL-Delegate for any given PEP, they may ask
the Steering Council to review the delegation.
If no volunteer steps forward, then the Steering Council will approach core
developers (and potentially other Python community members) with relevant
expertise, in an attempt to identify a candidate that is willing to serve as
BDFL-Delegate for that PEP. If no suitable candidate can be found, then the
PEP will be marked as Deferred until one is available.
Previously appointed BDFL-Delegates may choose to step down, or be asked to step
down by the Council, in which case a new BDFL-Delegate will be appointed in the
same manner as for a new PEP (including deferral of the PEP if no suitable
replacement can be found). In the event that a BDFL-Delegate is asked to step
down, this will overrule any prior acceptance or rejection of the PEP, and it
will revert to Draft status.
With the approval of the Steering Council, PEP review and resolution may also
occur on a list other than python-dev (for example, distutils-sig for packaging
related PEPs that don't immediately affect the standard library). In these
cases, the "Discussions-To" heading in the PEP will identify the appropriate
alternative list where discussion, review and pronouncement on the PEP will
occur.
When such standing delegations are put in place, the Steering Council will
maintain sufficient public records to allow subsequent Councils, the core
developers, and the wider Python community to understand the delegations that
currently exist, why they were put in place, and the circumstances under which
they may no longer be needed.
For a PEP to be accepted it must meet certain minimum criteria. It
must be a clear and complete description of the proposed enhancement.
The enhancement must represent a net improvement. The proposed
implementation, if applicable, must be solid and must not complicate
the interpreter unduly. Finally, a proposed enhancement must be
"pythonic" in order to be accepted by the BDFL. (However, "pythonic"
is an imprecise term; it may be defined as whatever is acceptable to
the BDFL. This logic is intentionally circular.) See PEP 2 [2]_ for
standard library module acceptance criteria.
"pythonic" in order to be accepted by the Steering Council. (However,
"pythonic" is an imprecise term; it may be defined as whatever is acceptable to
the Steering Council. This logic is intentionally circular.) See PEP 2 [2]_
for standard library module acceptance criteria.
Once a PEP has been accepted, the reference implementation must be
completed. When the reference implementation is complete and incorporated
@ -421,7 +474,7 @@ ReStructuredText_ allows for rich markup that is still quite easy to
read, but also results in good-looking and functional HTML. PEP 12
contains instructions and a template [4]_ for reStructuredText PEPs.
The PEP text files are automatically converted to HTML [5]_ for easier
The PEP text files are automatically converted to HTML [6]_ for easier
`online reading <https://www.python.org/dev/peps/>`__.
@ -469,10 +522,10 @@ following RFC 2822 continuation line conventions. Note that personal
email addresses in PEPs will be obscured as a defense against spam
harvesters.
The BDFL-Delegate field is used to record cases where the final decision to
approve or reject a PEP rests with someone other than the BDFL. (The
delegate's email address is currently omitted due to a limitation in the
email address masking for reStructuredText PEPs)
The BDFL-Delegate field is used to record the individual appointed by the
Steering Council to make the final decision on whether or not to approve or
reject a PEP. (The delegate's email address is currently omitted due to a
limitation in the email address masking for reStructuredText PEPs)
*Note: The Resolution header is required for Standards Track PEPs
only. It contains a URL that should point to an email message or
@ -666,16 +719,19 @@ References and Footnotes
for retrieving older revisions, and can also be browsed via HTTP here:
https://github.com/python/peps
.. [2] PEP 2, Procedure for Adding New Modules, Faassen
.. [2] PEP 2, Procedure for Adding New Modules
(http://www.python.org/dev/peps/pep-0002)
.. [3] PEP 9, Sample Plaintext PEP Template, Warsaw
.. [3] PEP 9, Sample Plaintext PEP Template
(http://www.python.org/dev/peps/pep-0009)
.. [4] PEP 12, Sample reStructuredText PEP Template, Goodger, Warsaw
.. [4] PEP 12, Sample reStructuredText PEP Template
(http://www.python.org/dev/peps/pep-0012)
.. [5] More details on the PEP rendering and publication process can be found
.. [5] PEP 13, Python Language Governance
(http://www.python.org/dev/peps/pep-0013)
.. [6] More details on the PEP rendering and publication process can be found
in the PEPs repo README at
https://github.com/python/peps/blob/master/README.rst