diff --git a/pep-0001.txt b/pep-0001.txt
index 9de5ffc19bf..454de3c556b 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 <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:
 
@@ -488,6 +490,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 |
@@ -522,6 +525,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
@@ -639,12 +646,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