Require BIPs be "beyond the ideation phase" before being merged

TheBlueMatt commented at 1:25 am on April 22, 2024: contributor

As the BIP process restarts, one general risk in the BIPs is that they become (even more of) a dumping ground for half-baked ideas which even the BIP champion does not work on after the BIP is assigned. While simply never merging new BIPs addresses this issue, this isn’t particularly sustainable, and we should instead have some concrete criteria here.

BIPs generally fall into a few categories with respect to when they should be considered ready for merge:

they’re not particularly controversial (and not about consensus) and move forward towards adoption in several ecosystem projects relatively quickly or,
they generate lots of discussion, lots of feedback, the champion actively pushes the BIP forward and makes sustained arguments for adoption over some extended time period (this generally applies to consensus changes).

As long as the BIP champion is relatively actively pushing for adoption (i.e. active on the BIP outside of the BIP text itself) and actively addressing feedback on the BIP, the BIP should be merged, however if the BIP hasn’t seen any adoption anywhere (outside of maybe one project the author wrote) and the BIP champion is off doing other things, I’d argue it clearly should simply be closed.

This commit adds some trivial but flexible text to that effect, requiring roughly the above criteria for merge.

I’d humbly suggest that we apply this criteria to new BIP number assignments (or at least BIP merges, even if they get a temporary number pre-merge) while we hash out whether this criteria makes sense.

Require BIPs be "beyond the ideation phase" before being merged

As the BIP process restarts, one general risk in the BIPs is that
they become (even more of) a dumping ground for half-baked ideas
which even the BIP champion does not work on after the BIP is
assigned. While simply never merging new BIPs addresses this issue,
this isn't particularly sustainable, and we should instead have
some concrete criteria here.

BIPs generally fall into a few categories with respect to when they
should be considered ready for merge:
 * they're not particularly controversial (and not about consensus)
   and move forward towards adoption in several ecosystem projects
   relatively quickly or,
 * they generate lots of discussion, lots of feedback, the champion
   actively pushes the BIP forward and makes sustained arguments for
   adoption over some extended time period (this generally applies
   to consensus changes).

As long as the BIP champion is relatively actively pushing for
adoption (i.e. active on the BIP outside of the BIP text itself)
and actively addressing feedback on the BIP, the BIP should be
merged, however if the BIP hasn't seen any adoption anywhere
(outside of maybe one project the author wrote) and the BIP
champion is off doing other things, I'd argue it clearly should
simply be closed.

This commit adds some trivial but flexible text to that effect,
requiring roughly the above criteria for merge.

4ee106096a

kanzure commented at 12:15 pm on April 22, 2024: contributor

“Has to exist for a while” is a good improvement. It doesn’t solve advanced persistent threats, but it is a modest improvement.

in bip-0002.mediawiki:57 in 4ee106096a

53@@ -54,6 +54,7 @@ For a BIP to be accepted it must meet certain minimum criteria.
54 It must be a clear and complete description of the proposed enhancement.
55 The enhancement must represent a net improvement.
56 The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
57+BIP drafts should not be merged until the idea has materially progressed beyond the ideation phase - it should have multiple implementations from independent authors released in different software packages, and/or have received material public discussion feedback from diverse contributors with the BIP champion actively working towards adoption for an extended time period. While BIPs are author documents which must only meet certain minimum criteria, the BIP editors should strive to ensure there are not an unnecessary number of BIPs which never progress into broad implementation across the bitcoin ecosystem.

jonatack commented at 3:58 pm on April 22, 2024:

Agree with the premise. I interpret the added text as partially redundant with lines 34-46 above, but not completely, and it provides a clarifying counterweight to line 51 (“The BIP editors will not unreasonably reject a BIP”). As such, I think could be helpful to editors as a guideline.

jonatack commented at 5:45 pm on April 22, 2024:

@TheBlueMatt Do you think this line in the repo README would need to be updated as part of this change?

“We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community.”

TheBlueMatt commented at 5:50 pm on April 22, 2024:

I think that line still makes sense - the editors are still not “making decisions” though I’d argue that the line in the readme may need to be stronger, bolt, and at the very top - even with this proposed change there will still be BIPs that are bad ideas and that people shouldn’t implement, that that should be clear to anyone casually glancing at the repo.

murchandamus commented at 4:17 pm on May 30, 2024:

This sounds like a fine idea, but I’m not convinced by the approach. So far, implementation was considered a requirement for a BIP to move to Final, and the Draft status was used for a BIP that was not yet recommended to be implemented, or more generally still open to major changes. Under BIP2, number assignment had been happening when BIPs got merged, so in Draft status.

While I agree that it’s not useful to have a huge number of BIPs that never get adopted, it already takes significant effort to write up ideas sufficiently comprehensive to meet the “high quality” and “provides sufficient information to implement from the BIP” criteria. If these two sentences were incorporated into our process, it would mean that we would only assign numbers to BIPs that are ready to progress to Final. This is a complete overhaul of the prior process and as such I would concur that this amendment rather be taken into account for a successor Process BIP instead of a change to BIP2. Either way, it seems to me that a number assignment would be useful long before a BIP is ready to progress to Final.

Perhaps when we update our process, we could consider an approach where a BIP can be merged to the repository as a Draft before assigning a number, named “BIP-draft-author-topic”, and then a number be assigned when a BIP progresses to Proposed.

jonatack commented at 4:01 pm on April 22, 2024: contributor

Concept ACK

luke-jr commented at 6:18 pm on April 22, 2024: member

Once there’s multiple implementations, it’s Final… seems like this would negate the Draft/Proposed stages?

TheBlueMatt commented at 6:46 pm on April 22, 2024: contributor

In some cases, yes, but in the general case no as we also allow something to be “beyond the ideation phase” as long as the author has gotten material feedback and has been actively working on it for a while. Its really about avoiding things getting merged that had someone post a bip, got no feedback, then the author moved on to other things.

ajtowns commented at 2:59 am on April 23, 2024: contributor

“it should have multiple implementations from independent authors released in different software packages” How are the multiple implementers meant to implement the same thing if they don’t have a spec to reference?

Likewise, “the BIP champion actively working towards adoption for an extended time period” seems to put the cart before the horse: “you should adopt my proposal so that it can be assigned a BIP number”.

OTOH, “have received material public discussion feedback from diverse contributors” is pretty reasonable at least. Could consider something along the lines of “proposals should not be assigned a BIP number if specification sections are incomplete or important details are absent making the proposal impossible or unnecessarily difficult to implement”.

TheBlueMatt commented at 1:15 pm on April 23, 2024: contributor

I believe you missed the or in the sentence :). The “have multiple implementations” thing is really just an escape valve such that if you have a few implementations already even if there wasn’t much discussion (because it wasn’t controversial) it can just be merged as a BIP. This was also explained in the PR description.

Likewise, “the BIP champion actively working towards adoption for an extended time period” seems to put the cart before the horse: “you should adopt my proposal so that it can be assigned a BIP number”.

More generally, however, no one should be waiting to encourage people to adopt their protocol just because its waiting to be merged as a BIP?!

ariard commented at 6:53 am on April 25, 2024: member

I think this shall be proposed as a new BIP of type “process”. And not an edit of BIP2.

The “multiple implementation” makes only sense if it’s related to consensus / p2p / wallet / cryptography scheme etc.

katesalazar commented at 5:17 pm on April 25, 2024: contributor

ACK 4ee106096a4b5b31b27ab4f0a98972cae250f24b

the “the bitcoin ecosystem” capitalization catches my eye (contradicts older custom?0), though, ~

On Thu, Apr 25, 2024 at 6:54 AM Antoine Riard @.***> wrote:

I think this shall be proposed as a new BIP of type “process”. And not an edit of BIP2.

The “multiple implementation” makes only sense if it’s related to consensus / p2p / wallet / cryptography scheme etc.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

murchandamus added the label Process on May 9, 2024

murchandamus commented at 4:18 pm on May 30, 2024: contributor

I am not convinced that the BIP2-based Process should be changed to this degree at this stage, but would prefer that this is considered during work on an updated process.

TheBlueMatt commented at 5:07 pm on June 7, 2024: contributor

Makes sense. Closing as it can go towards BIP 3.

TheBlueMatt closed this on Jun 7, 2024

Require BIPs be “beyond the ideation phase” before being merged #1570