bip-0002: allow anyone to inactivate, not reject

kallewoof commented at 10:02 am on October 13, 2020: member

Addresses the issue with needless and reckless rejecting of BIPs solely due to time passing. Instead allow anyone to inactivate a BIP. Rejection should be done based on BIP inapplicability.

This does not retroactively undo the rejections made so far.

See #1006 discussion for details.

Note: I didn’t realize there was an .svg source for the process.png file, so I rewrote the thing from scratch in latex. The .tex file is added in this commit. If people prefer, I will try to rewrite in the .svg format, but I put some effort into it so please compare the tex version first.

Todo:

Update svg; remove tex stuff.

michaelfolkson commented at 10:32 am on October 13, 2020: contributor

I would prefer “Inactive” rather than “Deferred.” There are two concerns here. The first is that “Rejected” sounds overly harsh given no rejection has taken place. (I agree). The second is that “Deferred” sounds like there has been consensus that it should be implemented but not at the current time (which won’t be the case in many examples).

I think “Inactive” avoids both these concerns.

bip-0002: allow anyone to inactivate, not reject

Addresses the issue with needless and reckless rejecting of BIPs solely due to time passing. Instead allow anyone to inactivate a BIP. Rejection should be done based on BIP inapplicability.

c5cd3bbd9f

kallewoof force-pushed on Oct 13, 2020

kallewoof renamed this:
~~bip-0002: allow anyone to defer, not reject~~
bip-0002: allow anyone to inactivate, not reject
on Oct 13, 2020

kallewoof commented at 10:45 am on October 13, 2020: member

@michaelfolkson Sounds good to me.

Added new status type “Inactive” and changed to that for the 3-year rule.

michaelfolkson commented at 11:23 am on October 13, 2020: contributor

Concept ACK.

Your description in the PR is much stronger than the actual change. You haven’t deleted references to “Rejected” status.

the Rejected status is hereby obsolete. (comment)

Personally I think we still need a Rejected status. It just isn’t applied in the case when a BIP becomes “Inactive” due to 3 years of inactivity.

There is also the the process path diagram to consider. I don’t think Inactive would need to be incorporated into this because presumably the BIP could become Inactive at any stage in the process.

in bip-0002.mediawiki:193 in c5cd3bbd9f outdated

189@@ -190,7 +190,7 @@ The BIP editor may also change the status to Deferred when no progress is being
190 
191 A BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.
192 
193-BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.
194+BIPs should be changed from Draft or Proposed status, to Inactive status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if any progress is made, or to Proposed status if it meets the criteria required as described in the previous paragraph.

michaelfolkson commented at 11:32 am on October 13, 2020:

s/if any progress is made/if any substantial revisions are made

I don’t think editing a typo should be enough to get out of Inactive status. It has to be somewhat substantial. If not a significant update on the original proposal then at least an update on where it sits 3 years on with relation to what has been implemented on Core/other related proposals during that period

kallewoof commented at 10:27 pm on October 13, 2020:

See, a BIP may be inactive because there’s no one working on a reference implementation or the like. In those cases, if the author or somebody makes progress on a reference implementation, they may not actually modify the BIP at all and still consider it “progress” enough that removing the inactive status is warranted.

luke-jr commented at 12:09 pm on October 13, 2020: member

BIP 2 is not subject to modifications at this point.

luke-jr closed this on Oct 13, 2020

luke-jr commented at 12:57 pm on October 13, 2020: member

To clarify: BIP 2 is already Active, so further modifications are not possible. A new BIP should be proposed for these changes.

maflcko commented at 1:00 pm on October 13, 2020: member

Then BIP 2 should be modified to allow changes made to itself. This is clarifying the wording of statuses, not coming up with a completely new idea. Writing a new BIP for such a change seems overkill and confusing.

michaelfolkson commented at 1:28 pm on October 13, 2020: contributor

We are flirting with time sink territory here.

BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.

I am only continuing discussion as I do think there is a valid concern here (rather than just draft BIP authors being upset at harsh wording). The above is the current wording. If a draft BIP becomes Rejected/Inactive due to 3 years of inactivity it has to “address public criticism of the proposal” to change status. But what if there was literally no public criticism, it entirely became Rejected/Inactive due to 3 years of inactivity? The draft BIP author has to find public criticism to address that may not have been present.

I also agree with @MarcoFalke that a new BIP for such a minor change is overkill.

luke-jr reopened this on Oct 13, 2020

gmaxwell commented at 4:25 pm on October 13, 2020: contributor

Writing a new BIP for such a change seems overkill and confusing.

The new bip could be a copy of the old one with a word changed… in cases where you’re considering deployed technology, that’s exactly the sort of action that might be justified so that its clear which someone is implementing.

In this case I think it matters less. … I think what is needed here is essentially a copy-editign change. Proposals sometimes are actually rejected. in so much as something ever can be, but in many cases its really subjective if a proposal was actually rejected vs just set aside until its positives outweighed the negatives. The term invites time wasting debate on a criteria that no one needs to determine, because what matters more often to people isn’t if it’s rejected but if it’s a live proposal that they need to pay attention to. I think “rejected” was intended to and has, in practice, encompassed that meaning– but it’s also clearly caused some amount of unnecessary dispute.

It would also be useful to people to know that something has been truly “rejected”– so they would be discouraged from submitting quasi-duplicates– but I think in a highly open process there just isn’t an unambiguous enough signal that you can usually mark bips with a clear cut criteria. … A lot of the purpose of forcing all BIPs into mailling list proposal is to get authors to give up on proposals that don’t stand a chance fast, so most things which could unambiguously receive a reject already don’t make it as far as getting numbers and what does is at least debatable as to why it is currently failing to get traction.

In any case, I don’t personally see a problem with making small changes to active bips that don’t “break compatibility”. Some tweak of language here is probably fine.

kallewoof commented at 10:40 pm on October 13, 2020: member

This change does make the Rejected state a bit unclear. In particular, there’s no rule for when something becomes Rejected and/or when it ceases to be in the Rejected status. I’m wondering if something like this would be good:

BIPs should be changed from Draft or Proposed status, to Inactive status, upon request by any person, if they have not made progress in three years, or to Rejected status, if there is outstanding public criticism and the champion has not made revisions that meaningfully address said criticism.

Such a BIP may be changed to Draft status if any progress is made or if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.

gmaxwell commented at 10:52 pm on October 13, 2020: contributor

I think that’s somewhat better. In practice I also think it would work like “rejected if the proposer thinks that it should be that and no one complaints, inactive otherwise (unless its actually active)”.

kallewoof commented at 11:04 pm on October 13, 2020: member

Added a part saying a champion may choose to reject their own proposal at any time and pushed as a standalone commit in case people object. (I’m not sure if the added volume warrants a new BIP or not. I’m neutral either way.)

kallewoof force-pushed on Oct 13, 2020

kallewoof commented at 9:56 am on October 14, 2020: member

process2

Proposed revision to the state diagram.

Edit: realized after going through the trouble of setting latex up and such that there’s a .svg file. I’ll hesitantly keep the tex. version for now but I guess people will prefer the easier-to-modify version. (How often do you tweak it tho…?)

kallewoof force-pushed on Oct 14, 2020

michaelfolkson commented at 12:18 pm on October 14, 2020: contributor

Approach ACK

Can it just be “FINAL” rather than “FINAL_ACTIVE”? It looks cleaner.

I don’t think there is any harm in keeping .svg and tex file in this repo. But yeah we absolutely want to avoid regular tweaks to this. @luke-jr was right to initially resist changes imo. It makes a mockery of the process if it keeps being changed to cater for a specific scenario or a specific individual’s motivations.

bip-0002: clarify rejection process a01ddaa6b4

kallewoof force-pushed on Oct 15, 2020

kallewoof commented at 3:49 am on October 15, 2020: member

process

Changed to “FINAL”. Note that original said “FINAL/ACTIVE”. I don’t think it’s a big deal to leave out active but can put it back if needed.

michaelfolkson commented at 11:03 am on October 15, 2020: contributor

I’m happy with this. The problem with FINAL/ACTIVE is that ACTIVE AND INACTIVE are referring to two different things. ACTIVE is referring to being active on the network and INACTIVE is referring to there being no activity on the BIP. Hence I think it is better to not include ACTIVE in FINAL/ACTIVE as I think it adds confusion.

Maybe worth getting @harding to look over this. I don’t want this causing confusion later on down the line. And as I’ve previously said this BIP should generally remain unchanged.

harding commented at 1:20 pm on October 15, 2020: contributor

Maybe worth getting @harding to look over this. I don’t want this causing confusion later on down the line.

The sentence being edited was already hard to understand due to excess commas; now it’s a little harder to understand. However, if if the goal is making a minimal edit, I think this is ok-ish.

However, having read the discussion in #1006, I’m not convinced this PR fully addresses the issue. I don’t get the impression from @maaku’s comments that he’d consider BIP98 “inactive” (but I hope he will comment here if I’m inferring incorrectly). It was my understanding that the BIP2 Comments-Summary field was meant to capture information about the community response to particular proposals; is there some reason we can’t use that? For example, someone could post something like:

Three years after the introduction of BIP98, it hasn’t seen any significant changes, isn’t used in any currently widely discussed consensus proposals, and isn’t part of any widely used Bitcoin network protocol. It may become a useful part of future proposals (or earlier proposals that see renewed interest) but there is currently no direct benefit to implementing it in Bitcoin software.

Then the Comments-Summary could be updated to: “Not in current use or part of any active proposal”. I think this should satisfy the concern about developers spending their limited time reading and maybe implementing BIPs like BIP98 which don’t currently provide significant benefits.

With regard to BIP2, the change could then be that proposals shouldn’t be rejected unless it’s clear they should never be implemented in their current form, e.g. they contain a security vulnerability.

maaku commented at 1:27 am on October 16, 2020: contributor

@harding, you are correct. This change of this PR is a bit of a tangent from the discussion that started in #1006.

I knew about the rule that any 3rd party can act to reject a BIP after 3 years of apparent inactivity. I had always understood this to be a process for dealing with abandoned BIPs, and to be used only when there was justifiable reason, like an unhandled security vulnerability. After all, the wording is that someone has to advocate for the rejection of a BIP; it’s not a state transition that happens automatically. In #1006 (and #1007, #1008, and many others when I then looked at this repo’s merge history) I was surprised to find that for some months now BIPs in Draft status have been routinely closed upon going 3 years without an update, with or without a stated reason.

I do not think that there should be an automatic transition of a BIP’s status based on nothing more than the passage of time. Changing that final state to “Inactive” instead of “Rejected” just softens the wording of something that shouldn’t happen regardless.

Then the Comments-Summary could be updated to: “Not in current use or part of any active proposal”. I think this should satisfy the concern about developers spending their limited time reading and maybe implementing BIPs like BIP98 which don’t currently provide significant benefits.

This discussion belongs in #1006, but BIP-98 is in current use and part of an active proposal.

With regard to BIP2, the change could then be that proposals shouldn’t be rejected unless it’s clear they should never be implemented in their current form, e.g. they contain a security vulnerability.

I would much prefer this approach.

kallewoof commented at 4:21 am on October 16, 2020: member

I think moving things to inactive state after they’ve been stuck for awhile could be a good idea. Outright rejection simply due to time passing is wrong. Either way, I have made an alternative proposal which changes the criteria for rejection to also require there to be an outstanding issue, such as a vulnerability or public criticism. See #1016.

Dizopizo approved

haleemshal approved

vostrnad approved

vostrnad commented at 2:40 pm on April 10, 2023: contributor

ACK a01ddaa

murchandamus commented at 8:25 pm on April 30, 2024: contributor

It seems to me that this topic should be considered if/when someone decides to work on a revised process to supersede BIP2.

ysangkok commented at 8:57 pm on April 30, 2024: contributor

@murchandamus Why should the rules of BIP-0002 not be applied while there is no successor? You imply in #1008, #1009 and #792 that BIP-0002 shouldn’t be applied. You claim that there is “an ongoing discussion”, but I see no recent discussion in here. Are you referring to #1570?

maaku commented at 9:08 pm on April 30, 2024: contributor

Because the purpose of the BIP system is to support bitcoin development. Mindlessly rejecting BIPs because of the mere passage of time and observance of process does not contribute towards that purpose.

ysangkok commented at 9:21 pm on April 30, 2024: contributor

Those BIPs have no chance of getting adopted. BIP-0002 has good reasons for preventing BIPs from staying in the Draft state for years on end. It is also a slippery slope to start questioning the rules when they are not convenient to you. Inconsistently applying the rules means that you are now incentivizing people to bring all kinds of irrelevant concerns, because you have shown that the rules don’t actually apply.

There is an advantage of having a BIP list with updated statuses. I shouldn’t even have to write this comment, it’s a reversal of how things should be. There is an established process, people have been complaining about it for years, but it’s the process that was decided on. And still you think the rules don’t apply to your BIP.

Your comment implies that BIP-0002 doesn’t support development. But Bitcoin has been developing for years with this system. Loads of BIPs have been marked final. Newcomers are encouraged by the fact that you can glean through the BIP list and see what was actually adopted and what wasn’t.

jonatack commented at 9:25 pm on April 30, 2024: contributor

Most reviewers here appear to be in favor of moving in the approximate direction of this PR, or at least to not reject BIPs solely due to the passage of time.

I think I’m supportive of #1012 (comment).

maaku commented at 1:22 am on May 1, 2024: contributor

The BIPs in question are still active proposals, with actively maintained implementations. Why are you advocating for closing active proposals?

murchandamus commented at 5:37 pm on May 2, 2024: contributor

@murchandamus Why should the rules of BIP-0002 not be applied while there is no successor? You imply in #1008, #1009 and #792 that BIP-0002 shouldn’t be applied. You claim that there is “an ongoing discussion”, but I see no recent discussion in here. Are you referring to #1570?

I’m referring to the discussions on the mailing list regarding new BIP editors and updating the BIP process.

murchandamus added the label Process on May 9, 2024

5twelve approved

bip-0002: allow anyone to inactivate, not reject #1012