All right, here are some suggested changes. Actual suggestions are indented; commentary and meta-information is not indented. On Mon, Jul 29, 2002, Barry A. Warsaw wrote:
Kinds of PEPs
There are two kinds of PEPs. A standards track PEP describes a new feature or implementation for Python. An informational PEP describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementors are free to ignore informational PEPs or follow their advice.
Add: Some informational PEPs become Meta-PEPs that describe the workflow of the Python project. Project contributions that fail to follow the prescriptions of Meta-PEPs are likely to be rejected.
If the PEP editor approves, he will assign the PEP a number, label it as standards track or informational, give it status 'draft', and create and check-in the initial draft of the PEP. The PEP editor will not unreasonably deny a PEP. Reasons for denying PEP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or 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 arbitrator of the draft's PEP-ability.
Substitute: If the PEP editor approves, he will assign the pre-PEP a number, label it as standards track or informational, give it status 'draft', and create and check-in the initial draft of the PEP. The PEP editor will not unreasonably deny a pre-PEP. Reasons for denying PEP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or 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 arbitrator of the draft's PEP-ability. Generally speaking, if a pre-PEP meets technical standards, it will be accepted as a PEP to provide a historical record even if likely to be rejected (see the later section on rejecting a PEP). (This is to clarify the distinction between denying a pre-PEP and rejecting a PEP later in the process.)
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.
Add (not sure whether it should be a separate paragraph): The PEP author is responsible for recording summaries of all arguments in favor and opposition. This is particularly important for rejected PEPs to reduce the likelihood of rehashing the same debates.
6. Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
I'm thinking we should add a section 9) titled "Discussion summary" to make it clearer that the PEP author is required to include this information. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Project Vote Smart: http://www.vote-smart.org/