[Python-checkins] r78677 - peps/trunk/pep-0001.txt

[brett.cannon]

Author: brett.cannon
Date: Fri Mar  5 04:07:12 2010
New Revision: 78677

Log:
Clarify the current practices of how to develop a PEP.

Modified:
   peps/trunk/pep-0001.txt

Modified: peps/trunk/pep-0001.txt
==============================================================================
--- peps/trunk/pep-0001.txt	(original)
+++ peps/trunk/pep-0001.txt	Fri Mar  5 04:07:12 2010
@@ -60,17 +60,18 @@
 PEP Work Flow
 =============
 
-The PEP editors assign PEP numbers and change their status.  The
-current PEP editors are David Goodger and Barry Warsaw.  Please send
+The PEP editors assign PEP numbers and change their status.  Please send
 all PEP-related email to <peps at python.org> (no cross-posting please).
 Also see `PEP Editor Responsibilities & Workflow`_ below.
 
 The PEP process begins with a new idea for Python.  It is highly
 recommended that a single PEP contain a single key proposal or new
-idea.  The more focussed the PEP, the more successful it tends to
-be.  The PEP editor reserves the right to reject PEP proposals if they
-appear too unfocussed or too broad.  If in doubt, split your PEP into
-several well-focussed ones.
+idea. Small enhancements or patches often don't need
+a PEP and can be injected into the Python development work flow with a
+patch submission to the Python `issue tracker`_. The more focussed the
+PEP, the more successful it tends to be.  The PEP editor reserves the
+right to reject PEP proposals if they appear too unfocussed or too
+broad.  If in doubt, split your PEP into several well-focussed ones.
 
 Each PEP must have a champion -- someone who writes the PEP using the
 style and format described below, shepherds the discussions in the
@@ -78,13 +79,31 @@
 the idea.  The PEP champion (a.k.a. Author) should first attempt to
 ascertain whether the idea is PEP-able.  Posting to the
 comp.lang.python newsgroup (a.k.a. python-list at python.org mailing
-list) is recommended.  Small enhancements or patches often don't need
-a PEP and can be injected into the Python development work flow with a
-patch submission to the Python `issue tracker`_.
+list) or the python-ideas mailing list is the best way to go about this.
 
-The PEP champion then emails the PEP editor <peps at python.org> with a
-proposed title and a rough, but fleshed out, draft of the PEP.  This
-draft must be written in PEP style as described below.
+Vetting an idea publicly before going as far as writing a PEP is meant
+to save the potential author time. Many ideas have been brought
+forward for changing Python that have been rejected for various
+reasons. Asking the Python community first if an idea is original
+helps prevent too much time being spent on something that is
+guaranteed to be rejected based on prior discussions (searching
+the internet does not always do the trick). It also helps to make sure
+the idea is applicable to the entire community and not just the author.
+Just because an idea sounds good to the author does not
+mean it will work for most people in most areas where Python is used.
+
+Once the champion has asked the Python community as to whether an
+idea has any chance of acceptance, a draft PEP should be presented to
+python-ideas.  This gives the author a chance to flesh out the draft
+PEP to make properly formatted, of high quality, and to address
+initial concerns about the proposal.
+
+Following a discussion on python-ideas, the proposal should be sent to
+the `python-dev list <mailto:python-dev at python.org>`__ with the draft
+PEP and the PEP editors <peps at python.org>.  This
+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
 as Standards Track, Informational, or Process, give it status "Draft",
@@ -96,16 +115,9 @@
 Dictator for Life, Guido van Rossum) can be consulted during the
 approval phase, and is the final arbiter of the draft's PEP-ability.
 
-If a pre-PEP is rejected, the author may elect to take the pre-PEP to
-the comp.lang.python newsgroup (a.k.a. python-list at python.org mailing
-list) to help flesh it out, gain feedback and consensus from the
-community at large, and improve the PEP for re-submission.
-
-The author of the PEP is then responsible for posting the PEP to the
-community forums, and marshaling community support for it.  As updates
-are necessary, the PEP author can check in new versions if they have
-SVN commit permissions, or can email new PEP versions to the PEP
-editor for committing.
+As updates are necessary, the PEP author can check in new versions if
+they have SVN commit permissions, or can email new PEP versions to
+the PEP editor for committing.
 
 Standards Track PEPs consist of two parts, a design document and a
 reference implementation.  The PEP should be reviewed and accepted
@@ -115,10 +127,9 @@
 or a URL to same -- before it can be considered Final.
 
 PEP authors are responsible for collecting community feedback on a PEP
-before submitting it for review.  A PEP that has not been discussed on
-python-list at python.org and/or python-dev at python.org will not be
-accepted.  However, wherever possible, long open-ended discussions on
-public mailing lists should be avoided.  Strategies to keep the
+before submitting it for review. However, wherever possible, long
+open-ended discussions on public mailing lists should be avoided.
+Strategies to keep the
 discussions efficient include: setting up a 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