Published on: 2016-03-10T00:37:46+00:00
The Bitcoin Improvement Proposals (BIPs) are currently overseen by the mailing list, which could lead to centralized control. A proposal has been made to replace the mailing list with a "public discussion medium" such as forums or conferences. Luke Dashjr has created a draft BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concern about too much control being given to those who control the mailing list and wiki.Luke Dashjr suggested keeping reviews on the mailing list while using author-chosen forums in addition to the Bitcoin Wiki. Ryan Grant questioned the process for changing the status of a BIP from Draft to Active when rough consensus is reached on the mailing list. Luke explained that the wiki page is for leaving comments after discussion is over, and all review should remain on the mailing list. He also suggested that any forum used for review should have indisputable records of moderation and user edits.Luke Dashjr has made changes to BIP 2 to reduce hard feelings during comments. He proposed that a BIP author gather new/edited comment titles and report them once a week. Mediawiki offers watchlists for this purpose, and the wiki as a whole should be verifiable.A draft BIP by Luke Dashjr provides clarification on the Status field, expands allowable licenses, and adds public comments. Feedback on the draft is welcome. BIP99 aims to establish safe deployment requirements for an uncontroversial hardfork, but the concept of "adoption consensus" needs a neutral term. Suggestions are sought to make this clearer.Dave Scotese suggested that rules and code define Bitcoin, but consensus is needed after release. Gavin Andresen expressed concern about the definition of "consensus" giving too much control to the mailing list and wiki. Suggestions to make the meaning of "consensus" clear are welcomed.Jorge Timón suggested finding another term for "consensus" in the BIP document to avoid confusion. Luke-Jr agreed and proposed using "concord rules/code" instead of "consensus rules/code".Gavin Andresen expressed concern about the definition of "consensus" in the BIP process, giving too much control to the mailing list and wiki. He added a statement clarifying that the criteria for updating the status of BIPs should not be used to oppose or reject a BIP.The overuse of the term "consensus" in various contexts has caused confusion. Suggestions for alternative terms are welcomed. Luke-Jr suggested replacing it with "nearly universal acceptance" or "ecosystem-harmonious".Luke Dashjr and Dave Scotese discussed the need for coordination among multiple applications providing their own implementations of API/RPC and corresponding BIPs. They agreed that only one application would be standard to avoid confusion. The status of a BIP and comments should be unrelated metrics. The author of a BIP should be allowed to specify other internet locations for comments, but this could potentially be abused.Luke Dashjr proposed a draft BIP that provides clarity on the Status field, expands allowable licenses, and introduces public comments. Gavin Andresen expressed concerns about the definition of "consensus" giving too much control to the mailing list and wiki.Dave Scotese addressed the question of multiple applications providing their own implementations of API/RPC and corresponding BIPs. He stated that only one such application should be standard to avoid confusion. The status of a BIP and comments should not influence each other. The author of a BIP should be allowed to specify other internet locations for comments, although this could be potentially abused.Luke Dashjr requested objections to reach consensus on formally defining consensus. Clear reasoning must be given for objections not deemed substantiated by the community. Comments on BIPs should be solicited on the bitcoin-dev mailing list and summarized fairly in the wiki. Wiki registration and monitoring should not be a required hurdle to participation.Luke Dashjr completed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. Comments and status are unrelated metrics. The author of a BIP can specify other internet locations for comments.Luke Dashjr proposed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concerns about the definition of "consensus" giving too much centralized control.Dave Scotese stated that multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. The status of a BIP and comments should not directly influence each other. The author of a BIP should be allowed to specify other internet locations for comments. Clear reasoning must be offered for objections not deemed substantiated by the community.Luke Dashjr requested objections for consensus on formally defining consensus.
Updated on: 2023-08-01T17:42:26.680157+00:00