Address Barry's comments and make a couple of other cleanups

pep-0001.txt

@@ -19,7 +19,7 @@ a new feature for Python or its processes or environment.  The PEP
 should provide a concise technical specification of the feature and a
 rationale for the feature.
 
-We intend PEPs to be the primary mechanisms for proposing new
+We intend PEPs to be the primary mechanisms for proposing major new
 features, for collecting community input on an issue, and for
 documenting the design decisions that have gone into Python.  The PEP
 author is responsible for building consensus within the community and
@@ -60,6 +60,16 @@ There are three kinds of PEP:
 PEP Work Flow
 =============
 
+
+Python's BDFL
+-------------
+
+There are several reference 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.
+
+
 Submitting a PEP
 ----------------
 
@@ -108,24 +118,29 @@ draft must be written in PEP style as described below, else it will be
 sent back without further regard until proper formatting rules are
 followed.
 
-If the PEP editor approves, he will assign the PEP a number, label it
+If the PEP editor approves, they will assign the PEP a number, label it
 as Standards Track, Informational, or Process, give it status "Draft",
 and create and check-in the initial draft of the PEP.  The PEP editor
 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 (Benevolent
-Dictator for Life, Guido van Rossum) can be consulted during the
-approval phase, and is the final arbiter of the draft's PEP-ability.
+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.
 
-Developers with commit privileges for the `PEP repository`_ may claim
+Developers with hg push privileges for the `PEP repository`_ may claim
 PEP numbers directly by creating and committing a new PEP. When doing so,
 the developer must handle the tasks that would normally be taken care of by
-the PEP editors (see `PEP Editor Responsibilities & Workflow`_).
+the PEP editors (see `PEP Editor Responsibilities & Workflow`_). This
+includes ensuring the initial version meets the expected standards for
+submitting a PEP. Alternately, even developers may choose to submit PEPs
+through the PEP editors. When doing so, let the PEP editors know you have
+hg push privileges and they can guide you through the process of updating
+the PEP repository directly.
 
 As updates are necessary, the PEP author can check in new versions if
 they have hg push privileges, or can email new PEP versions to
-the PEP editor for committing.
+the PEP editors for publication.
 
 Standards Track PEPs consist of two parts, a design document and a
 reference implementation.  The PEP should be reviewed and accepted
@@ -142,10 +157,11 @@ separate SIG mailing list for the topic, having the PEP author accept
 private comments in the early design phases, setting up a wiki page, etc.
 PEP authors should use their discretion here.
 
+
 PEP Review & Resolution
 -----------------------
 
-Once the authors have completed a PEP, they must inform the PEP editor
+Once the authors have completed a PEP, they must inform the PEP editors
 that it is ready for review.  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 pre-determined to be
@@ -157,12 +173,16 @@ revisions.
 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
 experienced to make the final decision on that PEP may offer to serve as
-the "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'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.
+
+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.
 
 For a PEP to be accepted it must meet certain minimum criteria.  It
 must be a clear and complete description of the proposed enhancement.
@@ -206,6 +226,20 @@ Some Informational and Process PEPs may also have a status of "Active"
 if they are never meant to be completed.  E.g. PEP 1 (this PEP).
 
 
+PEP Maintenance
+---------------
+
+In general, Standards track PEPs are no longer modified after they have
+reached the Final state. Once a PEP has been completed, the Language and
+Standard Library References become the formal documentation of the expected
+behaviour.
+
+Informational and Process PEPs may be updated over time to reflect changes
+to development practices and other details. The precise process followed in
+these cases will depend on the nature and purpose of the PEP being updated.
+
+
+
 What belongs in a successful PEP?
 =================================
 
@@ -307,6 +341,7 @@ optional and are described below.  All other headers are required. ::
     Post-History: <dates of postings to python-list and python-dev>
   * Replaces: <pep number>
   * Superseded-By: <pep number>
+  * BDFL-Delegate: <PEP czar's real name and email address>
   * Resolution: <url>
 
 The Author header lists the names, and optionally the email addresses
@@ -329,6 +364,9 @@ 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.
+
 *Note: The Resolution header is required for Standards Track PEPs
 only.  It contains a URL that should point to an email message or
 other web resource where the pronouncement about the PEP is made.*
@@ -337,8 +375,8 @@ While a PEP is in private discussions (usually during the initial
 Draft phase), a Discussions-To header will indicate the mailing list
 or URL where the PEP is being discussed.  No Discussions-To header is
 necessary if the PEP is being discussed privately with the author, or
-on the python-list or python-dev email mailing lists.  Note that email
-addresses in the Discussions-To header will not be obscured.
+on the python-list, python-ideas or python-dev email mailing lists.  Note
+that email addresses in the Discussions-To header will not be obscured.
 
 The Type header specifies the type of PEP: Standards Track,
 Informational, or Process.