BIP3: Address follow-ups from #1712

bip-0003.md

@@ -482,6 +482,7 @@ repository](https://github.com/bitcoin/bips) where it may get further feedback.
 For each new BIP pull request that comes in, an editor checks the following:
 
 * The idea has been previously discussed on the Bitcoin Development Mailing List
+* The described idea is on-topic for the repository
 * Title accurately describes the content
 * Proposal is of general interest and/or pertains to more than one Bitcoin project/implementation
 * Document is properly formatted
@@ -493,7 +494,7 @@ For each new BIP pull request that comes in, an editor checks the following:
 
 Editors do NOT evaluate whether the proposal is likely to be adopted.
 
-A BIP editor will:
+Then, a BIP editor will:
 
 * Assign a BIP number and BIP type in the pull request
 * Ensure that the BIP is listed in the [README](README.mediawiki)
@@ -503,7 +504,7 @@ The BIP editors are intended to fulfill administrative and editorial responsibil
 changes, and update BIP headers as appropriate.
 
 BIP editors may also, at their option, unilaterally make and merge strictly editorial changes to BIPs, such as
-correcting misspellings, fixing broken links, etc. as long as they do not change the meaning or conflict with the
+correcting misspellings, mending grammar mistakes, fixing broken links, etc. as long as they do not change the meaning or conflict with the
 original intent of the authors. Such a change must be recorded in the Changelog if it’s noteworthy per the criteria
 mentioned in the [Changelog](#changelog) section.
 
@@ -530,7 +531,7 @@ mentioned in the [Changelog](#changelog) section.
 #### BIP Format
 
 - The Standards Track type is superseded by the similar Specification type.[^standard-track]
-- Many sections are declared optional, it is up to the authors and audience to judge whether all relevant topics have
+- Many sections are declared optional; it is up to the authors and reviewers to judge whether all relevant topics have
   been comprehensively addressed and which topics require a designated section to do so.
 - "Other Implementations" sections are discouraged.[^OtherImplementations]
 - Auxiliary files are only permitted in the corresponding BIP’s subdirectory, as no one used the alternative of labeling
@@ -542,20 +543,20 @@ mentioned in the [Changelog](#changelog) section.
 
 #### Preamble
 
-- Comments-URI and Comment-Summary headers are dropped from the preamble.[^comments]
+- "Comments-URI" and "Comment-Summary" headers are dropped from the preamble.[^comments]
 - The "Superseded-By" header is replaced with the "Proposed-Replacement" header.
 - The "Post-History" header is replaced with the "Discussion" header.
 - The "Discussions-To" header is dropped as it has never been used in any BIP.
-- Introduce Deputies and optional Deputies header.
-- Titles may now be up to 50 characters.
-- Layer header is optional for Specification BIPs or Informational BIPs, as it does not make sense for all BIPs.[^layer]
-- Rename "Author" field to "Authors".
+- Introduce Deputies and optional "Deputies" header.
+- The BIP "Title" header may now contain up to 50 characters (increased from 44 in BIP 2).
+- The "Layer" header is optional for Specification BIPs or Informational BIPs, as it does not make sense for all BIPs.[^layer]
+- Rename the "Author" field to "Authors".
 
 ### Updates to Existing BIPs should this BIP be Activated
 
 #### Previous BIP Process
 
-This BIP supersedes BIP 2 as the guideline for the BIP process.
+This BIP replaces BIP 2 as the guideline for the BIP process.
 
 #### BIP Types
 
@@ -645,13 +646,13 @@ feedback, and helpful comments.
     ready to recommend their BIP for adoption. The term "ready" was also considered, but considered too subjective.
 [^rejection]: **Why can proposals remain in Draft or Complete indefinitely?**  
     The automatic 3-year timeout of BIPs has led to some disagreement in the past and seems unnecessary in cases where
-    the authors are still active in the community and still consider their idea worth pursuing. On the other hand,
-    Draft proposals that appear stale may be tested and cleared out after only one year which should achieve the main goal of
+    the authors remain active in the community and still consider their idea worth pursuing. On the other hand,
+    Draft proposals that appear stale may be closed after only one year, which should achieve the main goal of
     the original rule by limiting the effort and attention spent on proposals that never reach Complete.
 [^closed]: **Why was the Closed Status introduced?**  
     The Closed Status provides value to the audience by indicating which documents are only of historical significance.
-    Previously, the process had Deferred, Obsolete, Rejected, Replaced, and Withdrawn which all meant some flavor of
-    "work has stopped on this". The many statuses complicated the process, may have contributed to process fatigue, and
+    Previously, the process had Deferred, Obsolete, Rejected, Replaced, and Withdrawn, which all meant some flavor of
+    "work has stopped on this." The many statuses complicated the process, may have contributed to process fatigue, and
     may have resulted in BIPs’ statuses not being maintained well. The author of this BIP feels that all of the
     aforementioned can be represented by _Closed_ without significantly impacting the information quality of the
     overview table. Where the many Status variants provided minuscule additional information, the simplification is more