From: Christopher Allen <ChristopherA@lifewithalacrity•com>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP process friction
Date: Tue, 16 Jan 2024 22:55:03 -0800 [thread overview]
Message-ID: <CACrqygDJRtZN4Oo30=DaFO2KYkn1H+Daxh5cinHKz66Uvn9BVg@mail.gmail.com> (raw)
In-Reply-To: <Zac+rMC/c+qTmSxY@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 4049 bytes --]
On Tue, Jan 16, 2024 at 6:43 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> If people want to use it for bitcoin-related proposals that don't have
> anything to do with inquisition, that's fine; I'm intending to apply the
> policies I think the BIPs repo should be using, so feel free to open a PR,
> even if you already know I think your idea is BS on its merits. If someone
> wants to write an automatic-merge-bot for me, that'd also be great.
>
> If someone wants to reform the BIPs repo itself so it works better,
> that'd be even better, but I'm not volunteering for that fight.
>
I've no idea how to reform BIPs, but we have a similar problem with the
Blockchain Commons Research (BCR) vs Proposals (BCP), vs. specifications
that are emerging in various other standards groups (IETF, W3C, and we have
desire to submit some of these as BIPs as well).
We do a few things differently, one of which in particular might be useful
for the future of BIPs: we reset the numbers every year. So the first new
BCR (research proposal) for 2024 would be 2024-01. Also, when there is a
major change in an old BCR, we create a new number for it in the new year
it is update.
We also have a concept called "Status", which is a progression that only
moves forward if BCRs are actually implemented with a reference
implementation, and advances further when they have multiple
implementations (and thus are qualified moved over to BCP repo as it is
somewhat stable and no longer "research".). A last form is when a
specification has moved to be controlled by another standards group (such
as a BIP). If only one organization implements a BCR, it will never advance
to BCP.
Some form of Status for BIPs inspired by this concept could track if a BIP
was ever actually implemented by someone, or more ideally, implemented by
multiple people in multiple organizations, ideally in multiple languages.
Here is how we currently do status, and the status of our current
specifications:
https://github.com/BlockchainCommons/Research/blob/master/README.md#status
Each BCR has a status which is indicated by a symbol.
SymbolTitleDescription
❌❌ Withdrawn Of historic interest only. Withdrawn either because never came
into use or proved sufficiently problematic that we do not recommend its
usage in any way.
❌ Superseded Superseded by a newer BCR. We do not suggest implementing as
an output format, but you may still wish to implement as an input format to
maintain backward compatibility.
📙 Research Contains original research or proposes specifications that have
not yet been implemented by us. Offered to the community for consideration.
⭐️ Reference Implementation At least one reference implementation has been
released, usually as a library, and may include demos or other supporting
tools. This specification still remains very open to change because it has
not yet (to our knowledge) been implemented by additional parties.
⭐️⭐️ Multiple Implementations At least two (known) implementations exist,
at least one not by the owner of the reference implementation. Has
demonstrable community support. May still change due to the needs of the
community, but community feedback will be sought.
⭐️⭐️⭐️ Standards Track Typically at least two implementations, and is
considered stable and ready for standardization. Being proposed as a BIP,
IETF Internet Draft, or some other standardization draft format. Will
typically be moved to the BCP repo
<https://github.com/BlockchainCommons/bcps>. Though changes may still be
made to the specification, these changes will exclusively be to allow for
standardization, and will be conducted with community feedback.
⭐️⭐️⭐️⭐️ Standardized A specification has been standardized as a an IETF
RFC, BIP, or approved by some other standards body.
❌❌ after another status symbol is read, "...but withdrawn" and ❌ is read,
"...but superseded".
-- Christopher Allen
[-- Attachment #2: Type: text/html, Size: 11496 bytes --]
next prev parent reply other threads:[~2024-01-17 6:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 2:42 Anthony Towns
2024-01-17 6:55 ` Christopher Allen [this message]
2024-01-17 16:45 ` Luke Dashjr
2024-01-17 17:29 ` Michael Folkson
2024-01-18 18:00 ` Peter Todd
2024-01-19 19:27 ` Michael Folkson
2024-01-18 15:41 ` David A. Harding
2024-01-19 0:46 ` Anthony Towns
2024-01-19 2:33 ` Karl-Johan Alm
2024-01-18 16:47 ` alicexbt
2024-01-18 17:42 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACrqygDJRtZN4Oo30=DaFO2KYkn1H+Daxh5cinHKz66Uvn9BVg@mail.gmail.com' \
--to=christophera@lifewithalacrity$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox