Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+1 −0
Open

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
1 change: 1 addition & 0 deletions bip-0002.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,7 @@ For a BIP to be accepted it must meet certain minimum criteria.
It must be a clear and complete description of the proposed enhancement.
The enhancement must represent a net improvement.
The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


The BIP author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests.

Expand Down