WIP---working-on-review

Author: murchandamus

bip-0003.md

@@ -74,6 +74,7 @@ allows any community member to retain a complete copy of the archive easily.
 
 The BIPs repository neither tracks community sentiment nor ecosystem adoption[^adoption] of BIPs beyond
 the brief overview provided via the BIP status (see [Workflow](#workflow) below).
+Proposals are merged to this repository if they are on-topic and fulfill the editorial criteria.
 No formal or informal decision body governs Bitcoin development or decides acceptance[^acceptance] of BIPs.
 
 ## BIP Format and Structure
@@ -158,7 +159,7 @@ appear in the following order. Headers marked with "\*" are optional. All other
 * Version — The current version number of this BIP. See the [Changelog](#changelog) section below.
 * Requires — A list of existing BIPs the new proposal depends on. If multiple BIPs
   are required, they should be listed in one line separated by a comma and space (e.g., "1, 2").
-* Replaces[^proposes-to-replace] — BIP authors may place the numbers of one or more prior BIPs in the Replaces header to recommend that their
+* Replaces[^proposes-to-replace] — BIP authors may put the numbers of one or more prior BIPs in the Replaces header to recommend that their
   BIP succeeds, supersedes, or renders obsolete those prior BIPs.
 * Proposed-Replacement[^superseded-by-proposed-replacement] — When a later BIP indicates that it intends to supersede an
   existing BIP, the later BIP’s number is added to the Proposed-Replacement header of the existing BIP to indicate the
@@ -205,8 +206,8 @@ archive](https://gnusha.org/pi/bitcoindev/).
 
 It is recommended that authors establish before or at the start of working on a draft whether their idea may be of
 interest to the Bitcoin community.
-Vetting an idea publicly before investing time and effort to formally describe the idea is meant to save both the authors and
-the community time. Not only may someone point out relevant discussion topics that were missed in the authors’
+Vetting an idea publicly before investing time and effort to formally describe the idea is meant to save time both the authors and
+the community. Not only may someone point out relevant discussion topics that were missed in the authors’
 research, or that an idea is guaranteed to be rejected based on prior discussions, but describing an idea publicly also
 tests whether it is of interest to more people beside the authors.
 Authors should avoid opening a pull request with a BIP draft out of the blue.
@@ -712,7 +713,7 @@ feedback, and helpful comments.
     header with the "Proposed-Replacement" header that lists any proposals that recommend replacing the original document.
 [^proposes-to-replace]: **Why was "Replaces" retained instead of changing it to "Proposes-to-Replace"?**  
     When one BIP proposes to supersede another, it is on the original BIP where things get complicated. The BIP is an
-    author document, but depending on its progress through the Workflow, it may be meanwhile co-owned by community. Who may decide
+    author document, but depending on its progress through the workflow, it may meanwhile be co-owned by the community. Who may decide
     whether the original document should endorse a potential replacement BIP? Is it the original authors, the authors of the new
     proposal, the BIP Editors, some sort of community process, or a mix of all of the above?  
     On the new BIP these problems don’t exist in the same manner. As it is freshly written, it is wholly owned by its