BIP-0001: Updates #195

btcdrak commented at 10:43 AM on September 7, 2015: contributor

Clarified about BIP number assignment (not to self-assign, how numbers get assigned specifically).

in bip-0001.mediawiki:None in 5c9a212deb outdated

  80 | @@ -81,6 +81,8 @@ Each BIP should have the following parts:
  81 |  
  82 |  * Reference Implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.
  83 |  
  84 | +* Copyright notice -- BIPs must contain a copyright notice placing them in the public domain.

luke-jr commented at 7:45 PM on September 7, 2015:

We shouldn't require (nor encourage) public domain, as some jurisdictions don't recognise it as valid...

btcdrak commented at 7:46 PM on September 7, 2015:

If you dont require public domain then you have to add an additional requirement of permissive licensing, e.g. a specific CC license.

luke-jr commented at 7:48 PM on September 7, 2015:

Such a requirement is already in BIP 1.

btcdrak commented at 8:01 PM on September 7, 2015:

Ah yes, I missed that.

BIPs maintainers should not merge any BIP pull-requests unless that requirement is met.

in bip-0001.mediawiki:None in 5c9a212deb outdated

 152 | @@ -149,21 +153,23 @@ A BIP editor must subscribe to the Bitcoin development mailing list. All BIP-rel
 153 |  
 154 |  For each new BIP that comes in an editor does the following:
 155 |  
 156 | -* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.
 157 | +* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted and must be relevent to Bitcoin.

luke-jr commented at 7:46 PM on September 7, 2015:

This clause don't fit where you put it...

in bip-0001.mediawiki:None in 5c9a212deb outdated

 167 |  
 168 | -* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141).
 169 | +* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141) in the pull request comments.
 170 |  
 171 | -* Add the BIP to the [https://github.com/bitcoin/bips bitcoin/bips] repository on GitHub.
 172 | +* Merge the pull request when the author is ready (allowing some time for further peer review).

luke-jr commented at 7:47 PM on September 7, 2015:

Review was supposed to occur on the Bitcoin-Development ML before being submitted as a PR. Once it's a PR, it should be ready for merging immediately (pending author ACK, if submitted by non-author).

If we want to encourage PR discussion, adding a flag like [WIP] makes sense.

btcdrak commented at 7:50 PM on September 7, 2015:

I agree that's the ideal (to be ready for immediate merging), but in practice the meat gets fleshed out on the mailing list and then further peer review occurs in the PR. People are not looking for nits on the list, nor is it easy to track small nits on the mailing list. Github makes collaborative polishing a thing and we should imo, make use of it. Put another way, people are used to polishing in pull requests.

andre-amorim commented at 11:27 PM on November 15, 2015:

PR ? who come up with that such reduction ?

luke-jr commented at 7:49 PM on September 7, 2015: member

There's a lot of changes here. I suggest starting a new BIP intended to supercede BIP 1.

btcdrak force-pushed on Sep 7, 2015

btcdrak commented at 8:15 PM on September 7, 2015: contributor

There aren't lots of changes! We're simply emphasising the don't self assign numbers rule (which needs to be written down because it's a constant problem for @gmaxwell), and changing how numbers are assigned (not by email but by requesting in a the pull, because it's more efficient and auditable).

The point about WIP is totally optional because it is a departure from the norm not to have some final polishing peer review in pull requests. It's more of a common sense addition, not a change in rules.

sipa commented at 10:03 PM on September 7, 2015: member

I think this should be a different BIP that overrides BIP 1. We shouldn't update old BIPs because we want their meaning to change (beyond extra clarification, bugfixes, examples, references, ...).

btcdrak commented at 10:43 PM on September 7, 2015: contributor

Are we seriously going to require a new BIP for a small clarification of details or changing allocation of BIP numbers from email to PR?

Especially BIP-0001 is just a ruleset for how to manage BIPs in the first place.

sipa commented at 11:01 PM on September 7, 2015: member

It's a change to the semantics. I don't see why we should change an existing BIP for that.

btcdrak commented at 11:09 PM on September 7, 2015: contributor

The first BIP are the operating procedures for BIPs, unless there was some substantial change, like to the workflow (as I suggested on the ML), I really dont understand how the changes in this PR warrant a new BIP. It's incredibly wasteful - we're not writing legal statues... and these changes could help reduce some friction we've had because it's not explicitly written down and people keep doing things like self assign numbers.

We've been operating with "dont self assign numbers" for as long as I can remember. how is that a change of semantics? @gmaxwell has been plagued by people self assigning numbers, it needs to be documented surely: and documented or not, those are the rules we've been operating under.

Whether BIPs are assigned by pestering the BIP maintainer over email/IRC is requested in the body of the pull request is also such a small change it seems bizarre. Additionally, ever since we moved to Github, people have used PRs as a was to do final review (usually smaller nit, but sometimes larger ones). It works because it's more collaborative than the mailing list. Again it's not a change, it's how we have been operating, I am simply documenting the status quo.

btcdrak commented at 11:17 PM on September 7, 2015: contributor

Here's another example of something that went away when we migrated from the wiki to github

"If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions."

This isn't happening anymore. Authors write their BIPs, discuss on ML/IRC/privately and submit a PR when they have had enough feedback and feel it's ready. Any nits are dealt with in the pull request.

btcdrak force-pushed on Sep 7, 2015

btcdrak commented at 11:23 PM on September 7, 2015: contributor

I have removed superfluous changes. How about this?

maraoz commented at 11:29 PM on September 7, 2015: contributor

ACK

laanwj commented at 3:30 PM on September 8, 2015: member

@sipa I agree with that in general, but for the meta-bip I think it makes practical sense to make an exception there:

People will go to BIP1 to learn about writing BIPs. Having it self-contained is a plus
There are no implementations of BIP1 - unless you are sneaky and count the other BIPs, but that'd only matter if there are big structural changes which would 'invalidate' the other BIPs by BIP1

in bip-0001.mediawiki:None in 36dd1e8eb7 outdated

  24 | @@ -25,6 +25,8 @@ There are three kinds of BIP:
  25 |  
  26 |  The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#BIP_Editors|BIP Editors]] below. Also see [[#BIP_Editor_Responsibilities__Workflow|BIP Editor Responsibilities & Workflow]].
  27 |  
  28 | +Authors MUST NOT self assign numbers, but may use aliases such as "bip-exampleproposal".

andychase commented at 7:28 AM on September 9, 2015:

I have a feeling if someone is reading this BIP they are not the type of person that self-assigns.

The readme is the best place for this notice and it's already there (though should be formatted differently).

andychase commented at 7:43 AM on September 9, 2015:

~~Or not? I thought there was a notice in the readme but I guess I just imagined it.~~ Figured it out. It's in the raw source but doesn't show up on Github due to the way it's formatted: 

In that case I believe the notice should go in the readme after the numbers in bold. That's where people look to see that's free so you catch them just in time: "a simple reminder at the time of the temptation is usually all it takes for people to suddenly 'remember' their honesty."

gmaxwell commented at 4:41 AM on October 21, 2015:

can the example be changed to bip-johndoe-infinitebitcoins or the like? (I prefer to include the name as duplicate work sometimes gets merged as part of the pre-assignment)

andychase commented at 7:47 AM on September 9, 2015: contributor

@sipa @luke-jr

This BIP actually lists the criterion for replace vs edit right inside it:

BIPs can also be superseded by a different BIP, rendering the original obsolete. This is intended for Informational BIPs, where version 2 of an API can replace version 1.

If we completely revamped the BIP process it might make sense to allocate a new number so the change can be advertised more clearly but in this case the minor change in process should be edited in place to prevent confusion and fragmentation.

Also a "change log" should be added at the top like is done in BIP-0032 to preserve history.

Simplify clarifications aecb84f38d

btcdrak force-pushed on Oct 21, 2015

Added changelog f1320cfb1f

btcdrak force-pushed on Oct 21, 2015

luke-jr added the label Proposed BIP modification on Oct 23, 2015

gmaxwell referenced this in commit 989f276dcb on Nov 15, 2015

gmaxwell merged this on Nov 15, 2015

gmaxwell closed this on Nov 15, 2015

btcdrak deleted the branch on Jan 1, 2016

btcdrak cross-referenced this on Jan 1, 2016 from issue BIP1: Clarify and consolidate text regarding early stage idea championing by kanzure

luke-jr referenced this in commit 365a5a0f9f on Jan 20, 2018