Federico Berrone [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-15 📝 Original message:Hi Karl-Johan, I fully ...
📅 Original date posted:2021-09-15
📝 Original message:Hi Karl-Johan,
I fully agree with your proposal. In order to de-clutter BIPs and make a
more understandable proposal, we can add the additional information in a
separate piece. Also, this would maintain the original proposal without
any modifications, showing the original spirit of it.
Let me know how can I help you with your proposal.
Regards,
Federico Berrone.
P/D: This is my first participation in the bitcoin-dev list, sorry if I
am breaking any rule, I would be glad to know if that is the case.
El 15/09/2021 a las 8:14, Karl-Johan Alm via bitcoin-dev escribió:
> BIPs are proposals.
>
> They begin as ideas, are formulated and discussed on this list, and
> assuming no glaring flaws are observed, turned into pull requests to
> the bips repository, assigned a BIP number by the editors, and merged.
>
> 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. As entities place their weight behind a BIP,
> it makes less and less sense to consider its author the "maintainer"
> of the BIP, with rights to modify it at their whim. 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.
>
> BIPs are modified for primarily three reasons:
>
> 1. Because of spelling errors, or to otherwise improve on their
> description without changing what is actually proposed.
> 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.
>
> BIP extensions are separate BIPs that extend on or an existing BIP.
> BIP extensions do not require the approval of the extended-upon BIP's
> author, and are considered independent proposals entirely. A BIP that
> extends on BIP XXX is referred to as BIP-XXX-Y, e.g. BIP-123-1, and
> their introductory section must include the wording "
>
> This BIP extends on (link: BIP-XXX).
>
> ".
>
> By making extensions to BIPs, rather than modifying them long after
> review, we are giving the community
> 1. the assurance that a BIP will mostly remain in its form forever,
> except if an obvious win is discovered,
> 2. the ability to judge modifications to BIPs, such as activation
> parameters, on their merits alone, and
> 3. the path to propose modifications to BIPs even if their authors
> have gone inactive and cease to provide feedback, as is the case for
> many BIPs today, as BIP extensions do not require the approval of the
> extended-upon BIP.
>
> (Apologies if this has been proposed already. If so, feel free to
> ignore this message, and sorry to have wasted your time.)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB4B16B2D677120AF.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: OpenPGP public key
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210915/f2ca346f/attachment.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210915/f2ca346f/attachment.sig>;
📝 Original message:Hi Karl-Johan,
I fully agree with your proposal. In order to de-clutter BIPs and make a
more understandable proposal, we can add the additional information in a
separate piece. Also, this would maintain the original proposal without
any modifications, showing the original spirit of it.
Let me know how can I help you with your proposal.
Regards,
Federico Berrone.
P/D: This is my first participation in the bitcoin-dev list, sorry if I
am breaking any rule, I would be glad to know if that is the case.
El 15/09/2021 a las 8:14, Karl-Johan Alm via bitcoin-dev escribió:
> BIPs are proposals.
>
> They begin as ideas, are formulated and discussed on this list, and
> assuming no glaring flaws are observed, turned into pull requests to
> the bips repository, assigned a BIP number by the editors, and merged.
>
> 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. As entities place their weight behind a BIP,
> it makes less and less sense to consider its author the "maintainer"
> of the BIP, with rights to modify it at their whim. 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.
>
> BIPs are modified for primarily three reasons:
>
> 1. Because of spelling errors, or to otherwise improve on their
> description without changing what is actually proposed.
> 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.
>
> BIP extensions are separate BIPs that extend on or an existing BIP.
> BIP extensions do not require the approval of the extended-upon BIP's
> author, and are considered independent proposals entirely. A BIP that
> extends on BIP XXX is referred to as BIP-XXX-Y, e.g. BIP-123-1, and
> their introductory section must include the wording "
>
> This BIP extends on (link: BIP-XXX).
>
> ".
>
> By making extensions to BIPs, rather than modifying them long after
> review, we are giving the community
> 1. the assurance that a BIP will mostly remain in its form forever,
> except if an obvious win is discovered,
> 2. the ability to judge modifications to BIPs, such as activation
> parameters, on their merits alone, and
> 3. the path to propose modifications to BIPs even if their authors
> have gone inactive and cease to provide feedback, as is the case for
> many BIPs today, as BIP extensions do not require the approval of the
> extended-upon BIP.
>
> (Apologies if this has been proposed already. If so, feel free to
> ignore this message, and sorry to have wasted your time.)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB4B16B2D677120AF.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: OpenPGP public key
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210915/f2ca346f/attachment.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210915/f2ca346f/attachment.sig>;