On Wed, Sep 15, 2021 at 03:14:31PM +0900, Karl-Johan Alm via bitcoin-dev wrote: > BIPs are proposals.
> It is then organically incorporated into the various entities that > exist in the Bitcoin space. At this point, it is not merely a > proposal, but a standard. Thinking of BIPs that have reach "Final" status as a "standard" might be reasonable, but I'd be pretty careful about even going that far, let alone further. But as you said, "BIPs are proposals". If your conclusion is somehow that a BIP "is not merely a proposal", you're reached a contradiction, which means you've made a logic error somewhere in between... > Someone may have > agreed to the proposal in its original form, but they may disagree > with it if it is altered from under their feet. > 2. To improve the proposal in some way, e.g. after discussion or after > getting feedback on the proposed approach. > 3. To add missing content, such as activation strategy. > I propose that changes of the second and third type, unless they are > absolutely free from contention, are done as BIP extensions. If you were proposing this just for BIPs that are marked final, then sure, maybe, I guess -- though why mark them final if you still want to add missing content or make further improvements? But if you want to apply it as soon as a BIP number is assigned or text is merged into the repo, I think that just means requesting number assignment gets delayed until the end of the development process rather than near the beginning, which doesn't sound particularly helpful. That's essentially how the lightning BOLTs are set up -- you only get to publish a BOLT after you've got support from multiple implementations [0]; but that has meant they don't have published docs for the various things individual teams have implemented, making interoperability harder rather than easier. There's been talk about creating bLIPs [1] to remedy this lack. > BIP extensions are separate BIPs that extend on or an existing BIP. So as an alternative, how about more clearly separating out draft BIPs from those in Active/Final state? ie: * brand new BIP draft comes in from its authors/champions/whatever * number xxx gets assigned, it becomes "Draft BIP xxx" * authors modify it as they see fit * once the authors are happy with the text, they can move it to Final status, at which point it is no longer a draft and is just "BIP xxx", and doesn't get modified anymore * go to step 1 (I'm doubtful that it's very useful to have an "Active" state as distinct from "Final"; that just gives the editors an excuse to play favourites by deciding whose objections count and whose don't (or perhaps which implementations count and which ones don't). It's currently only used for BIPs about the BIP process, which makes it seem particularly pointless...) > By making extensions to BIPs, rather than modifying them long after > review, we are giving the community [...] As described, I think you would be giving people an easy way to actively obstruct the BIP process by making it harder to "improve the proposal" and "add missing content", and encouraging contentiousness as a result. For adding on to BIPs that have reached Final status, I think just assigning completely new numbers is fine, as occurred with bech32 and bech32m (BIPs 173 and 350). Even beyond that, having BIP maintainers exercising judgement by trying to reserve/assign "pretty" numbers (like "BIP 3" for the new BIP process) seems like a mistake to me. If it were up to me, I'd make the setup be something like: * new BIP? make a PR, putting the text into "drafts/bip-authorname-description.mediawiki" (with corresponding directory for images etc). Have the word "Draft" appear in the "BIP: xxx" header as well as in the Status: header. * if that passes CI and isn't incoherent, it gets merged * only after the draft is already merged is a BIP number assigned. the number is chosen by a script, and the BIP maintainers rename it to "drafts/bip-xxx.mediawiki" in a followup commit including internal links to bip-authorname-description/foo.png and add it to the README (automatically at the same time as the merge, ideally) * when a BIP becomes Final, it gets moved from drafts/ into the main directory [2], and to avoid breaking external links, drafts/bip-xxx.mediawiki is changed to just have a link to the main doc. * likewise when a BIP becomes rejected/deprecated/whatever, it's moved into historical/ and drafts/bip-xxx.mediawiki and bip-xxx.mediawiki are updated with a link to the new location * otherwise, don't allow any modifications to bips outside of drafts/, with the possible exception of adding additional info in Acknowledgements or See also section or similar, adding Superseded-By: links, and updating additional tables that are deliberately designed to be updated, eg bip-0009/assignments.mediawiki It's better to remove incentives to introduce friction rather than add more. Cheers, aj [0] https://github.com/lightningnetwork/lightning-rfc/blob/master/CONTRIBUTING.md [1] https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.md [2] Maybe moving the files between directories is too much, but I think having "drafts/" in the URL is likely to help ensure people referring to draft BIPs actually realise they're drafts, and thus subject to large changes, cf https://twitter.com/BobMcElrath/status/1281606259863629824 Likewise, people probably might not want to implement/deploy BIPs marked "draft", which is a good reason for the authors to mark them final, which in turn might help ensure they're actually complete and finished before they're deployed, all of which seems like a good thing. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
