Perhaps a BIP 3 is in order, but most of the real issue is simply a 
matter of volunteer time.

AJ's attempt to conflate that with his own personal disagreements with 
how BIPs have always worked, is unrelated.

Luke


On 1/17/24 01:55, Christopher Allen via bitcoin-dev wrote:
>
>
> 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.
>
> Symbol 	Title 	Description
> ❌❌ 	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 theBCP 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev