bip-0002: Rename Accepted Status to Proposed

Author: luke-jr

bip-0002.mediawiki

@@ -125,7 +125,7 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
 * Discussions-To: <email address>
 * Comments-Summary: <summary tone>
   Comments-URI: <links to wiki page for comments>
-  Status: <Draft | Active | Accepted | Deferred | Rejected |
+  Status: <Draft | Active | Proposed | Deferred | Rejected |
            Withdrawn | Final | Superseded>
   Type: <Standards Track | Informational | Process>
   Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
@@ -178,11 +178,11 @@ The typical paths of the status of BIPs are as follows:
 Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
 The BIP editor may also change the status to Deferred when no progress is being made on the BIP.
 
-A BIP may only change status from Draft (or Rejected) to Accepted, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.
+A BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.
 
-BIPs should be changed from Draft or Accepted status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Accepted status if it meets the criteria required as described in the previous paragraph.
+BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.
 
-An Accepted BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
+An Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
 
 When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
 
@@ -208,7 +208,7 @@ These criteria are considered objective ways to observe the de facto adoption of
 
 Why is this necessary at all?
 
-* BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion. As a result, many BIPs with significant real-world use have been left as Draft or Accepted status longer than appropriate. By giving objective criteria to judge the progression of BIPs, this proposal aims to help keep the Status accurate and up-to-date.
+* BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion. As a result, many BIPs with significant real-world use have been left as Draft or Proposed status longer than appropriate. By giving objective criteria to judge the progression of BIPs, this proposal aims to help keep the Status accurate and up-to-date.
 
 How is the entire Bitcoin economy defined by people selling goods/services and holders?
 
@@ -390,14 +390,15 @@ Why is Public Domain no longer acceptable for new BIPs?
 ==Changes from BIP 1==
 
 * Acceptable licenses are redefined entirely, allowing a wide variety of open licenses, while prohibiting the problematic older choices.
-* An implementation is now required (when applicable) before BIPs can proceed to Accepted Status.
+* An implementation is now required (when applicable) before BIPs can proceed to Proposed Status.
 * The License preamble headers have been added.
 * BIP Comments are newly introduced.
 * Non-image auxiliary files are permitted in the bip-XXXX subdirectory.
 * The Post-History header may be provided as a link instead of a simple date.
 * The Resolution header has been dropped, as it is not applicable to a decentralised system where no authority exists to make final decisions.
 * Email addresses are now required for authors.
 * Markdown format is no longer permitted for BIPs.
+* Accepted Status has been renamed to Proposed.
 
 ==See Also==