Make several minor improvements

Author: murchandamus

bip-0003.md

@@ -24,7 +24,7 @@ address the evolving needs of the BIP process.
 BIP 2 was written in 2016.
 This BIP revisits aspects of the BIP 2 process
 that did not achieve broad adoption, reduces the judgment calls assigned to the BIP Editor role, delineates the
-BIP types more clearly, and generalizes the BIP process to meet the community’s use of the repository.
+BIP types more clearly, and generalizes the BIP process to fit the community’s use of the repository.
 
 ## Fundamentals
 
@@ -39,7 +39,7 @@ the Bitcoin protocol, peer-to-peer network, and client software may be acceptabl
 BIPs are intended to be a means for proposing new protocol features, coordinating client standards, and
 documenting design decisions that have gone into implementations. BIPs may be submitted by anyone.
 
-The scope of the BIP
+The scope of the BIPs
 repository is limited to BIPs that do not oppose the fundamental principle that Bitcoin constitutes a peer-to-peer
 electronic cash system for the bitcoin currency.
 
@@ -48,7 +48,7 @@ electronic cash system for the bitcoin currency.
 Each BIP is primarily owned by its authors and represents the authors’ opinion or recommendation. The authors are
 expected to foster discussion, address feedback and dissenting opinions, and, if applicable, advance the adoption of
 their proposal within the Bitcoin community. As a BIP progresses through the workflow, it becomes increasingly
- co-owned by the Bitcoin community.
+co-owned by the Bitcoin community.
 
 #### Authors and Deputies
 
@@ -158,7 +158,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,11 +205,11 @@ 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’
+Authors should avoid opening a pull request with a BIP draft out of the blue.
+Vetting an idea publicly before investing time and effort to formally describe the idea is meant to save time for 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.
 
 As a first sketch of the proposal is taking shape, the authors should present it to the [Bitcoin Development Mailing
 List](https://groups.google.com/g/bitcoindev). This gives the authors a chance to collect initial feedback and address
@@ -446,7 +446,7 @@ In all cases, details of the licensing terms must be provided in the Copyright s
 #### Not Acceptable Licenses
 
 All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal.
-However, BIPs predating the acceptance of this BIP were allowed under other terms, and should use these abbreviations
+However, BIPs predating this proposal were allowed under other terms, and should use these abbreviations
 when no other license is granted:
 
 * PD: Released into the public domain
@@ -712,7 +712,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