PEP 1: Add approval criteria to section "Submitting a PEP". (#789)

Closes #788.

Reference: https://mail.python.org/pipermail/python-ideas/2018-September/053586.html

The criteria are taken from section "PEP Editor Responsibilities & Workflow" and edited to reflect the submitter's viewpoint.

Collateral damage: The format of the section was changed from bullet points without interpoint vertical whitespace to insert whitespace because rstpep2html doesn't like the more compact formatting I tried. A period was used to terminate the last bullet point.

pep-0001.txt

@@ -148,10 +148,37 @@ The standard PEP workflow is:
 * You, the PEP author, fork the `PEP repository`_, and create a file named
   ``pep-9999.rst`` that contains your new PEP.  Use "9999" as your draft PEP
   number.
+
+* In the "Type:" header field, enter "Standards Track",
+  "Informational", or "Process" as appropriate, and for the "Status:"
+  field enter "Draft".  For full details, see `PEP Header Preamble`_.
+
 * Push this to your GitHub fork and submit a pull request.
-* The PEP editors review your PR for structure, formatting, and other errors.
-* Once approved, they will assign your PEP a number, and label it as Standards
-  Track, Informational, or Process, and give it the status "Draft"
+
+* The PEP editors review your PR for structure, formatting, and other
+  errors.  For a reST-formatted PEP, PEP 12 is provided as a template.
+  It also provides a complete introduction to reST markup that is used
+  in PEPs.  Approval criteria are:
+
+  * It sound and complete.  The ideas must make technical sense.  The
+    editors do not consider whether they seem likely to be accepted.
+  * The title accurately describes the content.
+  * The PEP's language (spelling, grammar, sentence structure, etc.) 
+    and code style (examples should match PEP 8 & PEP 7) should be
+    correct and conformant.  The PEP will be checked for formatting
+    (plain text or reStructuredText) by Travis CI, and will not be
+    approved until this passes.
+
+  Editors are generally quite lenient about this initial review,
+  expecting that problems will be corrected by the reviewing process.
+  **Note:** Approval of the PEP is no guarantee that there are no
+  embarrassing mistakes!  Correctness is the responsibility of authors
+  and reviewers, not the editors.
+
+  If the PEP isn't ready for approval, an editor will send it back to
+  the author for revision, with specific instructions.
+
+* Once approved, they will assign your PEP a number.
 
 Once the review process is complete, and the PEP editors approve it (note that
 this is *not* the same as accepting your PEP!), they will squash commit your
@@ -564,12 +591,14 @@ For each new PEP that comes in an editor does the following:
 
 * The title should accurately describe the content.
 
-* Edit the PEP for language (spelling, grammar, sentence structure,
-  etc.), markup (for reST PEPs), code style (examples should match PEP
-  8 & 7).
+* 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
+  not required to do so.  (Text format is checked by Travis CI.)
 
 If the PEP isn't ready, an editor will send it back to the author for
-revision, with specific instructions.
+revision, with specific instructions.  If reST formatting is a
+problem, ask the author(s) to use PEP 12 as a template and resubmit.
 
 Once the PEP is ready for the repository, a PEP editor will:
 
@@ -580,6 +609,10 @@ Once the PEP is ready for the repository, a PEP editor will:
   Python 3 only, the process is back to using numbers in the 100s again.
   Remember that numbers below 100 are meta-PEPs.)
 
+* Check that the author has correctly labeled the PEP's type
+  ("Standards Track", "Informational", or "Process"), and marked its
+  status as "Draft".
+
 * Add the PEP to a local fork of the PEP repository.  For workflow
   instructions, follow `The Python Developers Guide <http://docs.python.org/devguide>`_