bitcoin-dev

Adding New BIP Editors

Adding New BIP Editors

Original Postby Pieter Wuille

Posted on: April 3, 2024 19:44 UTC

The discussion emphasizes the complexity of the Bitcoin Improvement Proposals (BIPs) process, highlighting that it involves more than just assigning numbers to proposals.

There is a nuanced debate over the role of BIP editors and the criteria for accepting BIPs. The conversation suggests refining these criteria to include aspects like formatting, editorial quality, prior discussion in relevant forums, necessity for standardization, and relevancy to technologies supporting the Bitcoin currency. This approach aims to clarify what makes a proposal suitable for consideration as a BIP, distinguishing it from mere software documentation.

There's an acknowledgment of the challenges in defining the scope of BIPs, with suggestions to limit inclusion to standards with broad applicability within the Bitcoin community. However, this raises issues around defining who constitutes this community and what technologies fall within this scope. The proposition leans towards excluding applications indirectly utilizing Bitcoin technology, like OpenTimestamps, to maintain focus on direct support for the Bitcoin currency. This criterion seeks to avoid arbitrary judgments while ensuring proposals are relevant to Bitcoin.

The dialogue also covers the evaluation of BIPs, arguing that editors should assess proposals based on soundness and completeness rather than predicting community acceptance. This stance advocates for a separation between the technical assessment of a BIP and value judgments about its potential adoption or alignment with the "Bitcoin philosophy." Furthermore, there is a consensus on revising the status fields in BIP submissions to reflect the author's intentions more accurately, suggesting simpler categories like "Draft," "Proposed," and "Withdrawn" that indicate the development stage without implying community endorsement.

Additionally, the conversation proposes documenting objective evidence of a BIP's acceptance by listing software projects that have implemented it, rather than relying on subjective perceptions of community consensus. For consensus changes, an "Accepted" status might be appropriate, provided it's based on concrete evidence of ecosystem agreement. The idea of requiring at least two independent and compatible software implementations is seen as a measure of a proposal's viability and relevance, reinforcing the need for standardization. Overall, the exchange calls for clearer guidelines and definitions in the BIP process to reduce ambiguity and ensure that proposals are evaluated fairly and consistently.