Clarify the current practices of how to develop a PEP.

pep-0001.txt

@@ -60,17 +60,18 @@ There are three kinds of PEP:
 PEP Work Flow
 =============
 
-The PEP editors assign PEP numbers and change their status.  The
+The PEP editors assign PEP numbers and change their status.  Please send
-current PEP editors are David Goodger and Barry Warsaw.  Please send
 all PEP-related email to <peps@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
+idea. Small enhancements or patches often don't need
-be.  The PEP editor reserves the right to reject PEP proposals if they
+a PEP and can be injected into the Python development work flow with a
-appear too unfocussed or too broad.  If in doubt, split your PEP into
+patch submission to the Python `issue tracker`_. The more focussed the
-several well-focussed ones.
+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 @@ appropriate forums, and attempts to build community consensus around
 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@python.org mailing
-list) is recommended.  Small enhancements or patches often don't need
+list) or the python-ideas mailing list is the best way to go about this.
-a PEP and can be injected into the Python development work flow with a
-patch submission to the Python `issue tracker`_.
 
-The PEP champion then emails the PEP editor <peps@python.org> with a
+Vetting an idea publicly before going as far as writing a PEP is meant
-proposed title and a rough, but fleshed out, draft of the PEP.  This
+to save the potential author time. Many ideas have been brought
-draft must be written in PEP style as described below.
+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@python.org>`__ with the draft
+PEP and the PEP editors <peps@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 @@ 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.
 
-If a pre-PEP is rejected, the author may elect to take the pre-PEP to
+As updates are necessary, the PEP author can check in new versions if
-the comp.lang.python newsgroup (a.k.a. python-list@python.org mailing
+they have SVN commit permissions, or can email new PEP versions to
-list) to help flesh it out, gain feedback and consensus from the
+the PEP editor for committing.
-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.
 
 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 @@ PEPs must include an implementation -- in the form of code, a patch,
 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
+before submitting it for review. However, wherever possible, long
-python-list@python.org and/or python-dev@python.org will not be
+open-ended discussions on public mailing lists should be avoided.
-accepted.  However, wherever possible, long open-ended discussions on
+Strategies to keep the
-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