PEP 1: Update language on sponsorships (#1170)

* Update language on sponsorships

pep-0001.txt

@@ -157,18 +157,21 @@ Submitting a PEP
 ----------------
 
 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.
+any of the PEP's co-authors are core developers. If one or more of the PEP's
+co-authors are core developers, they are responsible for following the process
+outlined below. Otherwise (i.e. none of the co-authors are core developers),
+then the PEP author(s) will need to find a sponsor for the PEP.
 
-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
+Ideally, a core developer sponsor is identified, but non-core sponsors may also
+be selected with the approval of the Steering Council.  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 a mentor).  Being a sponsor does **not**
+disqualify that person from becoming a co-author or BDFL-Delegate later on (but
+not both).  The sponsor of a PEP is recorded in the "Sponsor:" field of the
+header.
+
+Once the sponsor or the core developer(s) co-authoring the PEP deem 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).
@@ -512,7 +515,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>
+  * Sponsor: <real name of sponsor>
   * BDFL-Delegate: <PEP czar's real name>
   * Discussions-To: <email address>
     Status: <Draft | Active | Accepted | Provisional | Deferred | Rejected |
@@ -547,9 +550,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 Sponsor field records which developer (core, or otherwise approved by the
+Steering Council) 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
@@ -668,7 +672,9 @@ 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.
+* Make sure that the PEP is either co-authored by a core developer, has a core
+  developer as a sponsor, or has a sponsor specifically approved for this PEP
+  by the Steering Council.
 
 * 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