bitcoin-dev

Adding New BIP Editors

Adding New BIP Editors

Original Postby Tim Ruffing

Posted on: April 2, 2024 13:17 UTC

The discourse on the Bitcoin Improvement Proposal (BIP) process highlights several areas of concern and suggestions for improvement.

Firstly, the criteria outlined in BIP2 under the "BIP workflow" section for accepting a BIP are deemed extensive and somewhat subjective. Criteria such as avoiding duplication of effort, adhering to formatting rules, ensuring focus and technical soundness, providing proper motivation, addressing compatibility, and aligning with Bitcoin philosophy are required. However, the process to determine if an enhancement constitutes a net improvement is questioned for its reliance on subjective judgment.

Further complexity is added by the responsibilities assigned to BIP editors, as stated in the "BIP Editor Responsibilities & Workflow" section. Editors are expected to ensure that submissions are sound, complete, and technically sensible, even when acceptance within the community or by other stakeholders is uncertain. This responsibility appears to conflict with earlier stipulations about the broad criteria for rejecting BIPs. The definition of "acceptance" itself is unclear—whether it pertains to acceptance by the editor, the community, or another party is not specified.

Additionally, the recommendation for licensing BIPs under BSD-2 or BSD-3 clauses raises questions regarding their applicability to text documents, suggesting that CC0 might be a more suitable recommendation. The practice of using Comments-URI is considered outdated, with both the utility and implementation of the Comments-Summary field facing criticism for not effectively capturing community consensus or recommendations.

Specific requirements for different categories of BIPs, including those focusing on soft-forks, API/RPC layers, and peer services, are mentioned as problematic. These stipulate conditions like blockchain voting for soft-fork BIPs, implementation by at least two independent software applications for API/RPC layer BIPs, and adoption by a minimum percentage of public listening nodes for peer services BIPs. Such requirements are debated for their relevance and practicality.

In light of these issues, a proposal is made to simplify the BIP process by focusing on formal and editorial aspects such as formatting, licensing, readability, and spam filtering, rather than delving into the technical or philosophical merit of each BIP. This approach advocates for guiding authors on idea presentation without necessitating judgment on the content's merit by editors. A call to action encourages careful review of BIP2, accessible at GitHub, to foster informed discussion on proposed changes to the BIP process.