peps: bdbbd3ce97d9 (original) (raw)

--- a/pep-0001.txt +++ b/pep-0001.txt @@ -2,12 +2,12 @@ PEP: 1 Title: PEP Purpose and Guidelines Version: RevisionRevisionRevision Last-Modified: DateDateDate -Author: Barry Warsaw, Jeremy Hylton, David Goodger +Author: Barry Warsaw, Jeremy Hylton, David Goodger, Nick Coghlan Status: Active Type: Process Content-Type: text/x-rst Created: 13-Jun-2000 -Post-History: 21-Mar-2001, 29-Jul-2002, 03-May-2003 +Post-History: 21-Mar-2001, 29-Jul-2002, 03-May-2003, 05-May-2012 What is a PEP? @@ -60,6 +60,9 @@ 3. A Process PEP describes a process PEP Work Flow ============= +Submitting a PEP +---------------- + The PEP editors assign PEP numbers and change their status. Please send all PEP-related email to peps@python.org (no cross-posting please). Also see PEP Editor Responsibilities & Workflow_ below. @@ -115,6 +118,11 @@ not in keeping with the Python philosoph Dictator for Life, Guido van Rossum) 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 +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_). + 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. @@ -134,6 +142,9 @@ separate SIG mailing list for the topic, 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 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 @@ -143,6 +154,16 @@ has already been checked in) the BDFL ma first notifying the PEP author(s) and giving them a chance to make 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. + 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 @@ -154,8 +175,8 @@ the BDFL. This logic is intentionally c standard library module acceptance criteria. Once a PEP has been accepted, the reference implementation must be -completed. When the reference implementation is complete and accepted -by the BDFL, the status will be changed to "Final". +completed. When the reference implementation is complete and incorporated +into the main source code repository, the status will be changed to "Final". A PEP can also be assigned status "Deferred". The PEP author or editor can assign the PEP this status when no progress is being made @@ -164,7 +185,14 @@ to draft status. A PEP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this -fact. +fact. The "Withdrawn" status is similar - it means that the PEP author +themselves has decided that the PEP is actually a bad idea, or has +accepted that a competing proposal is a better alternative. + +When a PEP is Accepted, Rejected or Withdrawn, the PEP should be updated +accordingly. In addition to updating the status field, at the very least +the Resolution header should be added with a link to the relevant post +in the python-dev mailing list archives. PEPs can also be superseded by a different PEP, rendering the original obsolete. This is intended for Informational PEPs, where version 2 of @@ -420,17 +448,19 @@ Once the PEP is ready for the repository Python 3 only, we're back to using numbers in the 100s again. Remember that numbers below 100 are meta-PEPs.) -* List the PEP in PEP 0 (in two places: the categorized list, and the