BIP3 revisions #2037
BIP3 revisions #2037
Conversation
| ideation phase, e.g., by generating substantial public discussion and commentary from diverse contributors, by | ||
| independent Bitcoin projects working on adopting the proposal, or by the authors working for an extended period toward | ||
| improving the proposal based on community feedback, will be assigned a number by a BIP Editor. A number may be | ||
| ideation phase, will be assigned a number by a BIP Editor. |
There was a problem hiding this comment.
Noting here that I would like to think about this more. It seems to me that the bar for numbers might be too low and that standards on quality/proof of work, soundness, completeness, and originality may need reinforcing in light of the ease of lobbing LLM-generated slop or hallucinations over the fence at us.
There was a problem hiding this comment.
Given that this keeps the criteria as before and only drops the examples of how “progressed beyond ideation” may present, this seems like a disimprovement to me. Clearly, a list of examples is not meant to be considered exhaustive, perhaps you could suggest more examples how progressing beyond the ideation phase might present.
There was a problem hiding this comment.
The list of examples is too long IMO.
There was a problem hiding this comment.
Okay, I don’t think so. It’s fine.
| For each new BIP pull request that comes in, an editor checks the following: | ||
|
|
||
| * The idea has been previously proposed by one of the authors to the Bitcoin Development Mailing List and discussed there | ||
| * The idea has been previously proposed to the Bitcoin Development Mailing List and discussed there |
There was a problem hiding this comment.
Probably best to keep this as-is to avoid other people sniping/jumping on an idea.
Further, not only "The idea" but also the proposed draft for review on the author's own repository.
We're seeing new, out-of-the-blue github accounts (often with no established record or proof of work in the space) opening a PR directly to the BIPs, skipping the steps, and then using the "fait accompli" to protest the PR being closed.
There was a problem hiding this comment.
I don’t feel strongly about this one. I recall three cases in which a PR was opened by someone other than the person initially proposing an idea, twice consensual, once by surprise. It seems to me that this sort of thing sorts itself out.
I’d rather reiterate explicitly that both the idea and an early draft should be sent to the mailing list, or even require at least the latter as BIP 2 does.
There was a problem hiding this comment.
I split this up into two sentences, “The idea has been proposed and discussed” and “A draft by one of the authors has been previously discussed on the mailing list”.
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Thanks for your review.
| BIPs are intended to be a means for proposing new protocol features, coordinating client standards, and | ||
| documenting design decisions that have gone into implementations. A BIP may be submitted by anyone, | ||
| documenting design decisions that have gone into implementations thereof. | ||
| BIPs should cover topics that at least potentially have a need of standardization, involving multiple projects, and not merely configuration (such as default settings or per-node policies, except where the latter may overlap with standardized interactions). |
There was a problem hiding this comment.
Very similar language regarding proposals being relevant is already found in the workflow section below: “The idea must be of interest to the broader community or relevant to multiple software projects. Minor improvements and matters concerning only a single project usually do not require standardization and should instead be brought up directly to the relevant project.”
The rest of this suggestion also seems superfluous, as policy that is only relevant to one project is considered non-relevant per the quoted section, and policy that is relevant to multiple projects or otherwise of interest to the broader community could clearly be useful here.
| Authors may want additional help with the BIP process after writing an initial draft. In that case, they may assign | ||
| one or more Deputies to their BIP. Deputies are stand-in owners of a BIP who were not involved in writing the | ||
| document. They support the authors in advancing the proposal, or act as a point of contact for the BIP in the absence of the | ||
| one or more Deputies to their BIP. |
There was a problem hiding this comment.
Commit message:
“Remove assumption Author was involved in writing the original document”
The edited line describes Deputies, not Authors.
From Email:
- Authors/Deputies assumes the champion (Author) was involved in writing
the document. This is a deviation from the current process where the
champion can be reassigned by editors if the current one is MIA.
That’s one of the reasons to introduce Deputies: it allows us to appoint Authors or Deputies depending on the situation.
There was a problem hiding this comment.
It appears to contrast deputies to authors, and in doing so implies authors wrote the original document.
There was a problem hiding this comment.
Yes, the Authors are generally the people that wrote the original document. People that took over ownership at a later time would likely only be inserted as Deputies now that BIP 3 is deployed.
| Authors may choose to submit BIPs in MediaWiki or Markdown[^markdown] format. | ||
|
|
||
| Each BIP must have a _Preamble_, an _Abstract_, a _Copyright_, and a _Motivation_ section. Authors should consider all issues in the | ||
| Each BIP must have a _Preamble_, an _Abstract_, a _Motivation_, a _Specification, and a _Copyright_ section. |
There was a problem hiding this comment.
We have Informational BIPs that don’t have a Specification section, and it seems to me that Informational BIPs do not require a Specification section. The BIP Types section specifies that Specification BIPs require a Specification, and heavily implies that Process BIPs do, too (“Process BIPs are like Specification BIPs, …”).
| For each new BIP pull request that comes in, an editor checks the following: | ||
|
|
||
| * The idea has been previously proposed by one of the authors to the Bitcoin Development Mailing List and discussed there | ||
| * The idea has been previously proposed to the Bitcoin Development Mailing List and discussed there |
There was a problem hiding this comment.
I don’t feel strongly about this one. I recall three cases in which a PR was opened by someone other than the person initially proposing an idea, twice consensual, once by surprise. It seems to me that this sort of thing sorts itself out.
I’d rather reiterate explicitly that both the idea and an early draft should be sent to the mailing list, or even require at least the latter as BIP 2 does.
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
I have adopted the indicated changes in #2051.
| For each new BIP pull request that comes in, an editor checks the following: | ||
|
|
||
| * The idea has been previously proposed by one of the authors to the Bitcoin Development Mailing List and discussed there | ||
| * The idea has been previously proposed to the Bitcoin Development Mailing List and discussed there |
There was a problem hiding this comment.
I split this up into two sentences, “The idea has been proposed and discussed” and “A draft by one of the authors has been previously discussed on the mailing list”.
bip-0003.md
Outdated
| ### What is a BIP? | ||
|
|
||
| BIPs are improvement proposals for Bitcoin[^capitalization]. The main topic is information and technologies that support and expand the utility of the bitcoin | ||
| BIPs are improvement proposals for Bitcoin. The main topic is information and technologies that support and expand the utility of the bitcoin |
There was a problem hiding this comment.
Adopted with slight changes.
|
Did #2051 fairly address your points here? |
|
To a large extent, but there's a few remaining issues. Rebased to address those. |
|
Luke, I have responded to each of your remaining six suggestions both on the mailing list and here with explanations why I did not adopt them. Resubmitting exactly the same suggestions that I have already addressed without responding to any of my comments or further substantiation is not constructive and does not advance this conversation. I would also like to point out that it has been 34 days since I updated my proposal in response to your feedback and four weeks since Jon asked here whether your points have been addressed fairly. You did not reply or “update your PR” until less than one hour after I emailed the mailing list that my activation proposal has been updated in response to several other correspondents assessing that BIP 3 has rough consensus. Your behavior could easily be understood as deliberately wasting people’s time and resources. 
|
|
More like you are deliberately misunderstanding my intentions. Obviously an email that you have updated the BIP gets people to look at the updates. I still think these changes are an improvement. |
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
I can see why your stance here might make sense to you.
However, in the real world, where other people’s opinions can also have weight, I authored a proposal and you suggested changes to it. I evaluated your suggestions, adopted some, and explained why I declined some others. Doubling down on your opinion without addressing my explanations at all as if you’re expecting your opinion to obviously override my rebuttals is not compelling, especially while over a dozen people indicate that the text is acceptable as is.
I’m going to close this PR now, since BIP 3 was deployed. If you think these changes are worth going through a multi-week discussion on the mailing list and an attempt to find rough consensus for them — as is required for amending a Deployed Process BIP — please feel free to reopen it and get on that.
| Authors may want additional help with the BIP process after writing an initial draft. In that case, they may assign | ||
| one or more Deputies to their BIP. Deputies are stand-in owners of a BIP who were not involved in writing the | ||
| document. They support the authors in advancing the proposal, or act as a point of contact for the BIP in the absence of the | ||
| one or more Deputies to their BIP. |
There was a problem hiding this comment.
Yes, the Authors are generally the people that wrote the original document. People that took over ownership at a later time would likely only be inserted as Deputies now that BIP 3 is deployed.
| ideation phase, e.g., by generating substantial public discussion and commentary from diverse contributors, by | ||
| independent Bitcoin projects working on adopting the proposal, or by the authors working for an extended period toward | ||
| improving the proposal based on community feedback, will be assigned a number by a BIP Editor. A number may be | ||
| ideation phase, will be assigned a number by a BIP Editor. |
There was a problem hiding this comment.
Okay, I don’t think so. It’s fine.
| ### BIP Types | ||
|
|
||
| * A **Specification BIP** defines a set of technical rules describing a new feature or affecting the interoperability of implementations. The | ||
| distinguishing characteristic of a Specification BIP is that it can be implemented, and implementations can be compliant with |
There was a problem hiding this comment.
I’m not sure why you are hung-up on this. It’s obviously a fine term for what I’m trying to express.
| recommend adoption, implementation, or deployment of the BIP. Where applicable, the authors must ensure that any | ||
| proposed specification is solid, not unduly complicated, and definitive. Specification BIPs must come with or refer to a working reference implementation and comprehensive test vectors before they can be moved to Complete. Subsequently, the BIP’s content should only be | ||
| proposed specification is solid, not unduly complicated, and definitive. | ||
| Specification BIPs must come with or refer to a working reference implementation and should include comprehensive test vectors before they can be moved to Complete. |
There was a problem hiding this comment.
The definition of a Specification BIP is that it can be implemented. If it can be implemented, it can be tested. I don’t see why there would ever be an exception, but if you have a good example, please feel free to provide it. Given the hypothetical example you’ll provide, I would love to see whether it would be ambiguous whether test vectors are required.
4 participants
This addresses several issues identified in my review of BIP 3. Other unaddressed issues are being posted to the mailing list for further discussion.