diff --git a/pep-0001.txt b/pep-0001.txt
index 7caf168e381..92bedddd20c 100644
--- a/pep-0001.txt
+++ b/pep-0001.txt
@@ -94,12 +94,12 @@ the currently active Python core team members described in PEP 13 [5]_.
 Python's BDFL
 -------------
 
-Previous versions of this PEP used the title "BDFL-Delegate" for PEP decision makers. This was
-a historical reference to Python's previous governance model, where all design
-authority ultimately derived from Guido van Rossum, the original creator of the
-Python programming language. By contrast, the Steering Council's design
-authority derives from their election by the currently active core developers.
-Now, PEP-Delegate is used in place of BDFL-Delegate.
+Previous versions of this PEP used the title "BDFL-Delegate" for PEP decision
+makers. This was a historical reference to Python's previous governance model,
+where all design authority ultimately derived from Guido van Rossum, the
+original creator of the Python programming language. By contrast, the Steering
+Council's design authority derives from their election by the currently active
+core developers. Now, PEP-Delegate is used in place of BDFL-Delegate.
 
 
 PEP Editors
@@ -421,8 +421,10 @@ Each PEP should have the following parts/sections:
 3. Motivation -- The motivation is critical for PEPs that want to
    change the Python language, library, or ecosystem.  It should
    clearly explain why the existing language specification is
-   inadequate to address the problem that the PEP solves.  PEP
-   submissions without sufficient motivation may be rejected outright.
+   inadequate to address the problem that the PEP solves.  This can
+   include collecting documented support for the PEP from important
+   projects in the Python ecosystem.  PEP submissions without
+   sufficient motivation may be rejected.
 
 4. Rationale -- The rationale fleshes out the specification by
    describing why particular design decisions were made.  It should
@@ -694,6 +696,11 @@ For each new PEP that comes in an editor does the following:
   PEP 8 & PEP 7).  Editors may correct problems themselves, but are
   not required to do so.  (Text format is checked by Travis CI.)
 
+* If a project is portrayed as benefiting from or supporting the PEP, make sure
+  there is some direct indication from the project included to make the support
+  clear. This is to avoid a PEP accidentally portraying a project as supporting
+  a PEP when in fact the support is based on conjecture.
+
 If the PEP isn't ready, an editor will send it back to the author for
 revision, with specific instructions.  If reST formatting is a
 problem, ask the author(s) to use PEP 12 as a template and resubmit.