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: michaelfolk...@protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
