@@ -107,17 +107,7 @@ PEP Editors

The PEP editors are individuals responsible for managing the administrative

and editorial aspects of the PEP workflow (e.g. assigning PEP numbers and

changing their status). See `PEP Editor Responsibilities & Workflow`_ for

details. The current editors are:

* Chris Angelico

* Anthony Baxter

* Georg Brandl

* Brett Cannon

* David Goodger

* \R. David Murray

* Jesse Noller

* Berker Peksag

* Barry Warsaw

details.

PEP editorship is by invitation of the current editors, and they can be

contacted via the address <peps@python.org>, but you may only need to use this

@@ -166,10 +156,22 @@ initial concerns about the proposal.

Submitting a PEP

----------------

Following a discussion on python-ideas, the proposal should be submitted as a

draft PEP via a `GitHub pull request`_. The draft must be written in PEP

style as described below, else it will fail review immediately (although minor

errors may be corrected by the editors).

Following a discussion on python-ideas, the workflow varies based on whether

the PEP author is a core developer. If the PEP author is **not** a

core developer then the PEP author will need to find a core developer

*sponsor* for the PEP. The sponsor's job is to provide guidance to the PEP

author to help them through the logistics of the PEP process (somewhat acting

like mentor). For the core developer sponsoring, being a sponsor does **not**

disqualify them from becoming a co-author or BDFL-Delegate later on (but not

both). The core developer who becomes the sponsor of a PEP is recorded in the

"Sponsor:" field of the header.

Once a core developer is found that is willing to sponsor the PEP -- whether by

being an author of the PEP or specifically a sponsor -- and deems the PEP ready

for submission, the proposal should be submitted as a draft PEP via a

`GitHub pull request`_. The draft must be written in PEP style as described

below, else it will fail review immediately (although minor errors may be

corrected by the editors).

The standard PEP workflow is:

@@ -511,6 +513,7 @@ optional and are described below. All other headers are required. ::

PEP: <pep number>

Title: <pep title>

Author: <list of authors' real names and optionally, email addrs>

* Sponsor: <real name of core developer sponsoring>

* BDFL-Delegate: <PEP czar's real name>

* Discussions-To: <email address>

Status: <Draft | Active | Accepted | Provisional | Deferred | Rejected |

@@ -545,6 +548,10 @@ following RFC 2822 continuation line conventions. Note that personal

email addresses in PEPs will be obscured as a defense against spam

harvesters.

The Sponsor field records which core developer is sponsoring the PEP.

If one of the authors of the PEP is a core developer then no sponsor is

necessary and thus this field should be left out.

The BDFL-Delegate field is used to record the individual appointed by the

Steering Council to make the final decision on whether or not to approve or

reject a PEP. (The delegate's email address is currently omitted due to a

@@ -662,12 +669,16 @@ handled through GitHub issues and pull requests, but you may also use

For each new PEP that comes in an editor does the following:

* Make sure a core developer is either an author or a sponsor of the PEP.

* Read the PEP to check if it is ready: sound and complete. The ideas

must make technical sense, even if they don't seem likely to be

accepted.

* The title should accurately describe the content.

* The file name extension is correct (i.e. ``.rst``).

* Skim the PEP for obvious defects in language (spelling, grammar,

sentence structure, etc.), and code style (examples should conform to

PEP 8 & PEP 7). Editors may correct problems themselves, but are