PEP process changes triggered by the packaging PEPs

- allow a Discussion-To header to indicate the list for pronouncement
- allow version independent Standards track PEPs

pep-0001.txt

@@ -7,7 +7,8 @@ Status: Active
 Type: Process
 Content-Type: text/x-rst
 Created: 13-Jun-2000
-Post-History: 21-Mar-2001, 29-Jul-2002, 03-May-2003, 05-May-2012
+Post-History: 21-Mar-2001, 29-Jul-2002, 03-May-2003, 05-May-2012,
+              07-Apr-2013
 
 
 What is a PEP?
@@ -36,7 +37,10 @@ PEP Types
 There are three kinds of PEP:
 
 1. A **Standards Track** PEP describes a new feature or implementation
-   for Python.
+   for Python. It may also describe an interoperability standard that will
+   be supported outside the standard library for current Python versions
+   before a subsequent PEP adds standard library support in a future
+   version.
 
 2. An **Informational** PEP describes a Python design issue, or
    provides general guidelines or information to the Python community,
@@ -210,6 +214,12 @@ 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.
 
+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.
+
 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
@@ -401,12 +411,14 @@ email address masking for reStructuredText 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.*
 
-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, python-ideas or python-dev email mailing lists.  Note
-that email addresses in the Discussions-To header will not be obscured.
+For a PEP where final pronouncement will be made on a list other than
+python-dev, a Discussions-To header will indicate the mailing list
+or URL where the pronouncement will occur. A temporary Discussions-To header
+may also be used when a draft PEP is being discussed prior to submission for
+pronouncement. No Discussions-To header is necessary if the PEP is being
+discussed privately with the author, or on the python-list, python-ideas
+or python-dev 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.
@@ -422,9 +434,13 @@ number, while Post-History is used to record the dates of when new
 versions of the PEP are posted to python-list and/or python-dev.  Both
 headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001.
 
-Standards Track PEPs must have a Python-Version header which indicates
-the version of Python that the feature will be released with.
-Informational and Process PEPs do not need a Python-Version header.
+Standards Track PEPs will typically have a Python-Version header which
+indicates the version of Python that the feature will be released with.
+Standards Track PEPs without a Python-Version header indicate
+interoperability standards that will initially be supported through
+external libraries and tools, and then supplemented by a later PEP to
+add support to the standard library. Informational and Process PEPs do
+not need a Python-Version header.
 
 PEPs may have a Requires header, indicating the PEP numbers that this
 PEP depends on.