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

pep-0001.txt

@@ -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
+This PEP still uses the title "BDFL-Delegate" for PEP decision makers. This is
-for "Benevolent Dictator for Life" and refers to Guido van Rossum, the
+a historical reference to Python's previous governance model, where all design
-original creator of, and the final design authority for, the Python
+authority ultimately derived from Guido van Rossum, the original creator of the
-programming language.  (**Note:** since Guido's withdrawal as BDFL,
+Python programming language. By contrast, the Steering Council's design
-this position is vacant. See PEP 8000 for how the community plans to
+authority derives from their election by the currently active core developers.
-fill the vacancy.)
 
 
 PEP Editors
@@ -164,7 +191,7 @@ The standard PEP workflow is:
   * It sound and complete.  The ideas must make technical sense.  The
     editors do not consider whether they seem likely to be accepted.
   * The title accurately describes the content.
-  * The PEP's language (spelling, grammar, sentence structure, etc.) 
+  * The PEP's language (spelling, grammar, sentence structure, etc.)
     and code style (examples should match PEP 8 & PEP 7) should be
     correct and conformant.  The PEP will be checked for formatting
     (plain text or reStructuredText) by Travis CI, and will not be
@@ -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
+The PEP editors will not unreasonably deny publication of a PEP.  Reasons for
-status include duplication of effort, being technically unsound, not providing
+denying PEP status include duplication of effort, being technically unsound,
-proper motivation or addressing backwards compatibility, or not in keeping
+not providing proper motivation or addressing backwards compatibility, or not
-with the Python philosophy.  The BDFL can be consulted during the approval
+in keeping with the Python philosophy.  The Steering Council can be consulted
-phase, and is the final arbiter of the draft's PEP-ability.
+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
+style and consistency from the PEP editors.
-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.
 
-The final authority for PEP approval is the BDFL. However, whenever a new
+However, content review and final acceptance of the PEP must be requested of the
-PEP is put forward, any core developer that believes they are suitably
+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
+the BDFL-Delegate for that PEP, and they will then have the authority to approve
-is accepted by the other core developers and the BDFL, then they will have
+(or reject) that PEP. Individuals taking on this responsibility are free to seek
-the authority to approve (or reject) that PEP. This process happens most
+additional guidance from the Steering Council at any time, and are also expected
-frequently with PEPs where the BDFL has granted in principle approval for
+to take the advice and perspectives of other core developers into account.
-*something* to be done, but there are details that need to be worked out
-before the PEP can be accepted.
 
-If the final decision on a PEP is to be made by a delegate rather than
+The designated decision maker for each PEP is recorded in the "BDFL-Delegate"
-directly by the BDFL, this will be recorded by including the
+header in the PEP.
-"BDFL-Delegate" header in the PEP.
 
-PEP review and resolution may also occur on a list other than python-dev
+Such self-nominations are accepted by default, but may be explicitly declined by
-(for example, distutils-sig for packaging related PEPs that don't
+the Steering Council. Possible reasons for the Steering Council declining a
-immediately affect the standard library). In this case, the "Discussions-To"
+self-nomination as BDFL-Delegate include, but are not limited to, perceptions of
-heading in the PEP will identify the appropriate alternative list where
+a potential conflict of interest (e.g. working for the same organisation as the
-discussion, review and pronouncement on the PEP will occur.
+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"
+"pythonic" in order to be accepted by the Steering Council.  (However,
-is an imprecise term; it may be defined as whatever is acceptable to
+"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
+the Steering Council.  This logic is intentionally circular.)  See PEP 2 [2]_
-standard library module acceptance criteria.
+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
+The BDFL-Delegate field is used to record the individual appointed by the
-approve or reject a PEP rests with someone other than the BDFL. (The
+Steering Council to make the final decision on whether or not to approve or
-delegate's email address is currently omitted due to a limitation in the
+reject a PEP. (The delegate's email address is currently omitted due to a
-email address masking for reStructuredText PEPs)
+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