From 78b6b4409a26fc4e285c35ba9223e9801e7e6dac Mon Sep 17 00:00:00 2001 From: Murch Date: Fri, 20 Sep 2024 13:13:36 -0400 Subject: [PATCH] Reconsider uses of words that matched statuses --- bip-update-process.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/bip-update-process.md b/bip-update-process.md index 5138bbcb4..094524b1f 100644 --- a/bip-update-process.md +++ b/bip-update-process.md @@ -224,7 +224,7 @@ should delay number assignment when they perceive a proposal being met with lack assignment facilitates the distributed discussion of ideas, but before a proposal garners some interest in the Bitcoin community, there is no need to refer to it by a number. -Proposals are also not eligible for number assignment if they duplicate efforts, disregard formatting rules, are too +Proposals are also not ready for number assignment if they duplicate efforts, disregard formatting rules, are too unfocused or too broad, fail to provide proper motivation, fail to address backwards compatibility, or fail to specify the feature clearly and completely. Reviewers and BIP editors should provide guidance on how the proposal may be improved to progress toward readiness. Pull requests that are proposing off-topic or unserious ideas or have @@ -432,7 +432,7 @@ when it is addressed by authors. Substantive discussion of ideas may be more acc mailing list, where it is also more likely to be retained by the community memory. If the BIP needs more work, an editor should ensure that constructive, actionable feedback is provided to the author for -revision. Once the BIP is fleshed out it should be submitted as a "pull request" to the [BIPs +revision. Once the BIP is ready it should be submitted as a "pull request" to the [BIPs 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: @@ -445,14 +445,14 @@ For each new BIP pull request that comes in, an editor checks the following: * Motivation, Rationale, and Backward Compatibility have been addressed * Specification provides sufficient detail for implementation * The defined Layer header must be correctly assigned for the given specification -* The BIP is fit: it is complete, comprehensible, and technically feasible +* The BIP is ready: it is complete, comprehensible, and technically feasible Editors do NOT evaluate whether the proposal is likely to be adopted. A BIP editor will: * Assign a BIP number and BIP type in the pull request -* Merge the pull request when it is complete +* Merge the pull request when it is ready * List the BIP in the [README](README.mediawiki) The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP @@ -597,10 +597,10 @@ adapted from [BIP 2](BIP-0002.mediawiki) which was also licensed under the BSD After a Proposed or Active BIP has been deployed by one or more implementation, breaking changes to the specification could lead to a situation where multiple "compliant" implementations fail at being interoperable, because they implemented different versions of the same BIP. Therefore, even changes to the - specification of Proposed BIPs should be avoided, but active BIPs should never be subject to breaking changes to + specification of Proposed BIPs should be avoided, but Active BIPs should never be subject to breaking changes to their specification. [^settled]: **What is meant with a BIP being settled?** - Since active BIPs should not be changed, a Proposed BIP should only be moved to Active after its Specification + Since Active BIPs should not be changed, a Proposed BIP should only be moved to Active after its Specification has been put through its paces and changes to the BIP have stopped. [^licenses]: **Why were some licenses dropped?** Among the 141 BIPs with licenses in the repository, only nine licenses have ever been used to license BIPs (although,