[bitcoin-dev] Tuesday's BIP process meeting

[bitcoin-dev] Tuesday's BIP process meeting

[Michael Folkson]

[-- Attachment #1: Type: text/plain, Size: 3895 bytes --]

Tuesday's BIP process meeting was announced previously here [0].

A conversation log of the meeting is available here [1].

It looks promising at this stage that we'll eventually have a bundle of changes to warrant a new proposed BIP (BIP 3) to replace the current BIP process that is described in BIP 2 [2]. Obviously there was only a very small group of attendees at this week's IRC meeting and so there should (and will) be ample time for the community (and this list) to review whatever changes are proposed before they are considered for merging into the BIPs repository and before they take effect.

The following proposed changes were discussed:

1) An end to the 3 year rejection rule. In BIP 2 a BIP enters the "Rejected" state after 3 years if no progress had been made. The BIP champion then needs to address public criticism of the BIP to be able to leave the "Rejected" state. It is proposed instead that after 3 years the BIP would enter an "Inactive" state that only requires activity from the BIP champion to leave the "Inactive" state.

2) Currently BIP champions need to ACK pull requests with basic spelling/grammar changes before they can be merged. This is time consuming not only for the BIP editors who have to chase the BIP champions but it can be irritating for the BIP champions too especially if they champion multiple BIPs. It is proposed that BIP editors instead can use their judgment to merge in changes that don't impact the meaning of the BIP cc'ing the BIP champions and with reversions possible if the BIP champion is unhappy with the change. A single pull request making changes across multiple BIPs (e.g. spelling corrections) will not be considered for merging however.

3) BIP comments were introduced so that subject matter experts and informed critics of a proposal could make it clear to BIP readers and implementers of possible defects with the proposal. However, they have been rarely used and the few comments submitted on BIPs seem to have been widely ignored. Instead it is proposed that link(s) to bitcoin-dev mailing list post(s) with criticism or outlines of defects can be included within a BIP by the BIP editors such that the interested reader can easily be directed to the source of that information.

4) BIP champion(s) of soft fork BIPs containing consensus changes could theoretically include an activation method and parameters in their BIP unilaterally without consulting the broader community. (To be clear this is not necessarily what happened with Taproot activation parameters but there was confusion and disagreement about the role of BIPs and BIP editors in the perceived "finalization" of activation parameters.) This needs further discussion but proposed changes include sharpening the wording around activation parameters to make it clear that any parameters included are merely those recommended by the BIP champion(s) and don't necessarily have community consensus. Alternative proposals would be to not include activation methods or parameters within the BIP at all or to give BIP editors latitude to highlight concerns in a bitcoin-dev mailing list post and then include a link to that post within the BIP.

For details of other changes discussed in the meeting please see the conversation log [1]. Kalle Alm has also sent an email [3] on BIP extensions to this list.

The next meeting is on Wednesday September 29th (23:00 UTC) on the Libera IRC channel #bitcoin-dev.

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019412.html
[1]: https://gist.github.com/michaelfolkson/f2870851bb812b4ac86006ea54ca78a2
[2]: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki
[3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019457.html

Michael Folkson
Email: michaelfolkson@protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

[-- Attachment #2: Type: text/html, Size: 4745 bytes --]