This PR addresses feedback from the mailing list and a recent pull request to BIP 3. The following functional changes are made:
A Changelog section is added and backfilled, and a few editorial improvements are made. The Version header is omitted at this time, since it is not permitted under BIP 2.
This reverts commit d083ce5a9b9d96bbbedec94a3c7878df11edd085.
Based on Luke Dashjr’s b46e8195914fc3479760fef4c443390c01825e63
ACK 4429b139fc397fa8c24cca6081586fc4f594fd5e
480 | @@ -481,22 +481,23 @@ repository](https://github.com/bitcoin/bips) where it may get further feedback. 481 | 482 | For each new BIP pull request that comes in, an editor checks the following: 483 | 484 | -* The idea has been previously proposed by one of the authors to the Bitcoin Development Mailing List and discussed there 485 | +* The idea has been previously proposed to the Bitcoin Development Mailing List and discussed there
Why remove this? It helps avoid sniping.
The way I understood the request, it seemed the most transparent to revert the whole commit. Regarding whether the idea must have been proposed by the same person writing the BIP: We have had only three instances in which BIP drafts came from other people than the ones proposing an idea. One was a misunderstanding (AJ suggesting to Chris to help, while Antoine wasn’t in the loop), the others explicitly said that they won’t pursue their idea and it’s up for grabs. I also added a second line here, that states that the authors’ BIP draft has to have been discussed, which seems more important to me.
-* 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
* The described idea is on-topic for the repository
+* A draft of the BIP by one of the authors has been previously discussed on the Bitcoin Development Mailing List
BIP110 was an example as well.
the others explicitly said that they won’t pursue their idea and it’s up for grabs
We had a case like this recently where the discussion author said that on social media (X), rather than in the list thread, causing confusion as well.
Ok, the latest change you propose LGTM.
492 | * Motivation, Rationale, and Backward Compatibility have been addressed 493 | * Specification provides sufficient detail for implementation 494 | -* The defined Layer header must be correctly assigned for the given specification 495 | -* The BIP is ready: it is comprehensible, technically feasible and sound, and all aspects are addressed as necessary 496 | +* The defined Layer and Type headers must be correctly assigned for the given specification 497 | +* The BIP is ready: it is comprehensible, technically feasible, and all aspects are addressed as necessary
Why remove soundness?
That was collateral damage of rolling back the AI-guidance commit, but lemme add it back in a separate commit.
Added it back in a later commit.
Adopted from:
https://github.com/bitcoin/bips/pull/2037/commits/a399d0791d173510badd3cbf954be547c3d347e4k
Co-authored-by: luke+github_public@dashjr.org
Co-authored-by: Luke Dashjr <luke-jr+git@utopios.org>
The Version header is omitted at this time, as it is not permitted under BIP 2.
40 | BIPs are intended to be a means for proposing new protocol features, coordinating client standards, and 41 | -documenting design decisions that have gone into implementations. A BIP may be submitted by anyone, 42 | -provided it is the original work of its authors and the content is of high quality, e.g. does not waste 43 | -the community's time. No content may be generated by AI/LLMs and authors must proactively disclose 44 | -up-front any use of AI/LLMs. 45 | +documenting design decisions that have gone into implementations. BIPs may be submitted by anyone.
This not only removes the AI guidance, but also that the content be of high-quality and not waste the community's time.
Edit, wider discussion, not necessarily for here:
It may be useful to set expectations, e.g. (simplifying), whether we're (a) relatively strict about the quality of what is accepted and it being in-scope, and thereby validated/legitimized by inclusion, versus (b) giving most everything a number and making everyone happy, at the risk of diluting the value of the repository.
It was my understanding that the “original work” part was also controversial, e.g., @real-or-random had pushed back on that. High quality is already required in the first line of the Draft section, but I’d be fine with reiterating here and stating that people shouldn’t waste the community’s time.
@jonatack: I added a commit to add language to that effect. Please let me know whether that meets your expectations.
Thanks
nit: s/their/the/ content
Taken, thanks.
-"bip-title.[md|mediawiki]". Only BIP Editors may assign BIP numbers. Until one has done so authors should refer to their
+"bip-title.[md|mediawiki]". Only BIP Editors may assign BIP numbers. Until one has done so, authors should refer to their
Co-authored-by: jon@atack.com
625 | @@ -626,9 +626,6 @@ feedback, and helpful comments. 626 | has frequently led to confusion, with authors using the date of opening the pull request, the date they started 627 | writing their proposal, the date of number assignment (as prescribed), or various other dates. Aligning the name of 628 | the header and the text in the preamble template with the descriptions will reduce the confusion. 629 | -[^capitalization]: **When is Bitcoin capitalized and when is it lowercased?** 630 | - This document uses capitalized Bitcoin to refer to the system, network and abstract concept, and only uses lowercase 631 | - bitcoin to refer to units of the bitcoin currency.
Your previous use of capitalization seemed preferable to me. Not a big deal either way.
A reviewer pointed out that the currency unit “bitcoin” never appears in the document, and as far as I can tell, all instances of Bitcoin otherwise refer to the system, which I would capitalize. Either way, I think capitalization of the word Bitcoin should not be a blocker.
ACK c6375317696e88868d14e451f91ad4f12520bc0d
Looks good to me. Overall, the changes are minor with the exception of removing the explicit ban on LLM-generated content.
This is an important document which is important to get right, and i understand that we want to keep refining it. But it is also a living one, which can be updated and improved after being activated, and is already a substantial improvement over the current process. I hope we can collectively come to an agreement soon and conclude this years-long effort.
Co-authored-by: jon@atack.com
reACK 897fa1b9dfd0eb77996144e83c1e1cc63a49bf6a
:+1:
41 | -documenting design decisions that have gone into implementations. A BIP may be submitted by anyone, 42 | -provided it is the original work of its authors and the content is of high quality, e.g. does not waste 43 | -the community's time. No content may be generated by AI/LLMs and authors must proactively disclose 44 | -up-front any use of AI/LLMs. 45 | +documenting design decisions that have gone into implementations. BIPs may be submitted by anyone, provided the 46 | +content is of high quality, e.g., does not waste the community’s time.
Would something roughly like this (didn't cross-verify with the rest of the BIP) be a good idea? (to discourage skipping steps and opening a PR prematurely)
content is of high quality and the process followed, e.g., does not waste the community’s time.
The ease with which LLMs are enabling people to submit complete-looking, "thorough" techno-babbly drafts (h/t Greg Maxwell) might be counteracted somewhat byy insisting on following the process of discussing first the idea, and then maybe later a draft, on the list before opening a PR here.
Since the whole document is providing guidance for participating in the process, the suggestion that the process should be followed does not strike me as controversial. I’d prefer to wrap on making changes, though, as every additional change resets prior ACKs. Would it be fine with you to relegate this to a follow-up?
SGTM (for a possible follow-up).
Great, thanks. I’ll leave this unresolved so it won’t be missed for the follow-up.
ACK
LGTM
ACK 897fa1b9dfd0eb77996144e83c1e1cc63a49bf6a