Introduce the concept of sponsors (#903) · python/peps@c58d32c (original) (raw)

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

107

`The PEP editors are individuals responsible for managing the administrative

108

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

109

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

110

details. The current editors are:

111

-

112

Chris Angelico

113

Anthony Baxter

114

Georg Brandl

115

Brett Cannon

116

David Goodger

117

\R. David Murray

118

Jesse Noller

119

Berker Peksag

120

Barry Warsaw

110

details.

121

111

122

112

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

123

113

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

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

166

156

`Submitting a PEP

167

157

`----------------

168

158

169

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

170

`` -

draft PEP via a GitHub pull request_. The draft must be written in PEP

171

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

172

errors may be corrected by the editors).

159

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

160

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

161

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

162

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

163

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

164

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

165

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

166

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

167

"Sponsor:" field of the header.

168

+

169

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

170

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

171

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

172

`` +

GitHub pull request_. The draft must be written in PEP style as described

173

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

174

corrected by the editors).

173

175

174

176

`The standard PEP workflow is:

175

177

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

511

513

` PEP:

512

514

` Title:

513

515

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

516

Sponsor:

514

517

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

515

518

` * Discussions-To:

516

519

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

545

548

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

546

549

`harvesters.

547

550

551

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

552

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

553

necessary and thus this field should be left out.

554

+

548

555

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

549

556

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

550

557

`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

662

669

663

670

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

664

671

672

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

673

+

665

674

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

666

675

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

667

676

` accepted.

668

677

669

678

`* The title should accurately describe the content.

670

679

680


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

681

+

671

682

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

672

683

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

673

684

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