bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-08-18 13:26:23 +00:00
Code Issues Releases Wiki Activity

bip3: Describe acceptance as Adoption/Publication

Browse Source
This commit is contained in:
Murch 2025-06-27 09:52:54 -07:00
parent 2c57d8aee6
commit 7101294a93
No known key found for this signature in database
GPG Key ID: 7BA035CA5B901713
1 changed files with 18 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
bip-0003.md
View File

@ -72,10 +72,10 @@ Through its high visibility, it facilitates the community-wide consideration of
source to retrieve the latest version of any BIP. The repository transparently records all changes to each BIP and
allows any community member to retain a complete copy of the archive easily.
The BIPs repository is not a tool to track acceptance[^acceptance], adoption, or community consensus on BIPs, beyond
providing a brief overview of BIP statuses (see [Workflow](#workflow) below) to the audience.
There is no formal or informal decision body that governs Bitcoin development or decides acceptance of BIPs. Bitcoin
development emerges from the participation of stakeholders across the ecosystem.
The BIPs repository neither tracks community sentiment[^acceptance] nor ecosystem adoption[^adoption] of BIPs beyond
the brief overview provided via the BIP status (see [Workflow](#workflow) below).
Proposals are published in this repository if they are on-topic and fulfill the editorial criteria.
No formal or informal decision body governs Bitcoin development or decides adoption of BIPs.
## BIP Format and Structure
@ -540,7 +540,7 @@ mentioned in the [Changelog](#changelog) section.
- "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
them with the BIP number.
- Tracking of adoption, acceptance, and community consensus is out of scope for the BIPs repository, except to determine
- Tracking of community consensus and adoption is out of scope for the BIPs repository, except to determine
whether a BIP is in active use for the move into or out of the Deployed status.
- The distinction between recommended and acceptable licenses was dropped.
- Most licenses that have not been used in the BIP process have been dropped from the list of acceptable licenses.
@ -661,10 +661,19 @@ feedback, and helpful comments.
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
valuable and the Changelog section now collects specific details.
[^acceptance]: **Why does the BIPs repository no longer track adoption?**
BIP 2 made an attempt to gather community feedback into comment summaries in BIPs directly. Given the low adoption
and corresponding low information quality of the summaries that resulted from that feature, this BIP instead intends
to leave the evaluation of BIPs to the audience.
[^acceptance]: **When is a BIP "accepted"?**
Many standards processes such as the PEPs or the IETF have a mechanism for a proposal to be formally accepted by
some council or committee. The BIP Process does not have such a decision body. Bitcoin development and "acceptance"
of BIPs emerges from the participation of stakeholders across the ecosystem, and refers to some vague notion of community
interest and support for a proposal.
BIP 2 had made an attempt to gather community feedback into comment summaries in BIPs directly. Given the low
participation and corresponding low information quality of the summaries that resulted from that feature, this BIP
instead intends to leave the evaluation of BIPs to the reviewers and users.
[^adoption]: **Why does the BIPs repository no longer track adoption?**
In the past, some BIPs maintained lists of projects that had implemented the BIP. These lists generated
noise for subscribers of the repository, often listed implementations of questionable quality, and quickly
grew outdated, therefore providing little value. The repository no longer tracks which projects have implemented
BIPs. Instead, it is recommended that projects publish a list of the BIPs they implement.
[^markdown]: **Which flavor of Markdown is allowed?**
The author of this proposal has no opinion on Markdown flavors, but recommends that proposals stick to the basic
Markdown syntax features commonly shared across Markdown dialects.