From dda159ddb4a88f295b3717d743b5016f83b08be2 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Fri, 1 Mar 2019 14:08:06 -0800 Subject: [PATCH 1/2] Introduce the concept of sponsors --- pep-0001.txt | 41 ++++++++++++++++++++++++++--------------- 1 file changed, 26 insertions(+), 15 deletions(-) diff --git a/pep-0001.txt b/pep-0001.txt index 9de5ffc19bf..4f471b8407c 100644 --- a/pep-0001.txt +++ b/pep-0001.txt @@ -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 , 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 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. 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: @@ -488,6 +490,7 @@ optional and are described below. All other headers are required. :: PEP: Title: Author: + * Sponsor: * BDFL-Delegate: * Discussions-To: Status: Date: Mon, 4 Mar 2019 17:21:59 -0800 Subject: [PATCH 2/2] Feedback --- pep-0001.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/pep-0001.txt b/pep-0001.txt index 4f471b8407c..454de3c556b 100644 --- a/pep-0001.txt +++ b/pep-0001.txt @@ -160,11 +160,11 @@ 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 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. The core developer -who becomes the sponsor of a PEP is recorded in the "Sponsor:" field of the -header. +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