From 12ff0d6e7289ef7a79cfd0426a23d0c57fc45862 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Fri, 5 Mar 2010 03:07:12 +0000 Subject: [PATCH] Clarify the current practices of how to develop a PEP. --- pep-0001.txt | 63 ++++++++++++++++++++++++++++++---------------------- 1 file changed, 37 insertions(+), 26 deletions(-) diff --git a/pep-0001.txt b/pep-0001.txt index 0ea42ea0e..69706fc8f 100644 --- a/pep-0001.txt +++ b/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 -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 (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 @@ 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 -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 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 `__ with the draft +PEP and the PEP editors . 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 -the comp.lang.python newsgroup (a.k.a. python-list@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 @@ 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 -python-list@python.org and/or python-dev@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