Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id F421CC0037 for ; Wed, 17 Jan 2024 16:46:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id C17A441FDE for ; Wed, 17 Jan 2024 16:46:12 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C17A441FDE Authentication-Results: smtp4.osuosl.org; dkim=pass (1024-bit key) header.d=dashjr.org header.i=@dashjr.org header.a=rsa-sha256 header.s=zinan header.b=ADUXWzBX X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r401dkTRUew for ; Wed, 17 Jan 2024 16:46:11 +0000 (UTC) Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp4.osuosl.org (Postfix) with ESMTP id 4AB6641F43 for ; Wed, 17 Jan 2024 16:46:11 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4AB6641F43 Received: from [192.168.86.103] (99-39-46-195.lightspeed.dybhfl.sbcglobal.net [99.39.46.195]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 17435143730 for ; Wed, 17 Jan 2024 16:46:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan; t=1705509969; bh=IfHiVGB/O6Rzv0HDwkkhDxUQ7eVnpf7NKJ9/oT4xBfY=; h=Date:Subject:To:References:From:In-Reply-To; b=ADUXWzBXv/2r6ZFdlF8BJqeq9qgSr6zu2kUv8VkqsP0Kw7vvTIe6V7N1+olbXecuE YRn9X9ltBIzw5zYCvpVsLGxPtjYFxXNN/Lwfw93y7ng3oHl8Alhh78j0W+IWRTY5V/ rLrrCKvc1rQOWLX2dzT9h5GcHxBehGzFj9k8tOR4= X-Hashcash: 1:23:240117:bitcoin-dev@lists.linuxfoundation.org::4gH7m+Ox/hYYGTpU:1Jwu Content-Type: multipart/alternative; boundary="------------RI3ea25P7f0SROxwRJOJsFU0" Message-ID: <030e09b8-3831-45ff-92ad-9531ae277f80@dashjr.org> Date: Wed, 17 Jan 2024 11:45:59 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US, en-GB To: bitcoin-dev@lists.linuxfoundation.org References: From: Luke Dashjr In-Reply-To: Subject: Re: [bitcoin-dev] BIP process friction X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2024 16:46:13 -0000 This is a multi-part message in MIME format. --------------RI3ea25P7f0SROxwRJOJsFU0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 > 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 > . 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 --------------RI3ea25P7f0SROxwRJOJsFU0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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 the BCP repo. 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
--------------RI3ea25P7f0SROxwRJOJsFU0--