BIP1: Clarify and consolidate text regarding early stage idea championing #269

kanzure commented at 5:47 PM on January 1, 2016: contributor

The BIP1 text has been updated to clarify how early stage idea championing works.

The text itself is not significantly different, for the most part these changes involved reordering the existing sentences and paragraphs, and removing some conflicting ambiguous details. LIkewise, the previous reasons for BIP editor rejection of a (e.g. malformed) BIP have been consolidated into closer proximity in the text. I suspect that this will help readers understand the process better.

Also, this branch includes some trivial boring BIP1 changes like:

"Bitcoin mailing list" -> "bitcoin-dev mailing list"
"Bitcoin repository" -> "relevant Bitcoin repository" (originally I was going for "Bitcoin Core" but Luke-Jr mentioned a good NACK reason)
"Bitcoin issue tracker" -> "relevant Bitcoin issue tracker" (same reasoning)

I originally brought up the issue (of BIP1 early-stage championing ambiguity) in the bitcoin-dev IRC channel on freenode a few hours ago: http://bitcoinstats.com/irc/bitcoin-dev/logs/2016/01/01#l1451664846.0

Only somewhat related, but I found this email interesting: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010955.html

This pull request text was written as of commit 66224130f03ffb94daae9692d1b8d25b1c35e6ba.

BIP1: trivial formatting change bada79afdd

BIP1: clarify "issue tracker" statement

This switches from specifying "Bitcoin issue tracker" to specifying
"Bitcoin Core issue tracker". Other issue trackers are useful for other
client development activities, although this does not seem necessary to
mention.

c1261ac647

BIP1: clarify early stages of BIP championing

The previous BIP1 text was ambiguous regarding early steps for taking an
idea from concept and eventually into a BIP. The new text is intended to
make it more clear that the initial email to the bitcoin-dev mailing
list should not be a fully-formed BIP. There have been exceptions to
this in the past for ideas already widely known and implementation in
progress, but "you know it when you see it". Hopefully this will add
clarity to the BIP authoring process and work flow for new authors.

ea1111226f

BIP1: use "relevant Bitcoin issue tracker" instead

Also, remove an unnecessarily duplicated sentence.

e1628bb408

in bip-0001.mediawiki:None in ea1111226f outdated

35 |
36 | -Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum) is the best way to go about this.
37 | +BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.
38 |
39 | -Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used.
40 | +It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin Core development work flow with a patch submission to the Bitcoin Core issue tracker. If in doubt, split your BIP into several well-focused ones.

kanzure commented at 5:50 PM on January 1, 2016:

This sentence is said twice:

Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin Core development work flow with a patch submission to the Bitcoin Core issue tracker.

wasn't intentional, should be removed/fixed.

kanzure force-pushed on Jan 1, 2016

BIP1: fix changelog formatting 17dda103e9

btcdrak commented at 6:24 PM on January 1, 2016: contributor

I'd like to quote [@laanjw](/bitcoin-bips/contributor/laanjw/) for why BIP1 should be updated rather than creating a new BIP.

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

evoskuil commented at 7:56 PM on January 1, 2016: contributor

NACK: process references to bitcoin core and #bitcoin-dev

kanzure commented at 8:03 PM on January 1, 2016: contributor

@evoskuil These changes do not include a reference to the bitcoin-dev IRC channel on freenode. Also, is the one remaining use of "Bitcoin Core" at the end regarding committers still objectionable to you? It's pretty harmless, I think.

It was previously:

Many BIPs are written and maintained by developers with write access to the Bitcoin codebase.

And in this changeset it is currently:

Many BIPs are written and maintained by developers with write access to the Bitcoin Core codebase.

evoskuil commented at 8:48 PM on January 1, 2016: contributor

Hi @kanzure,

I don't see any reason for the reference to Bitcoin Core. One could just as easily change it to libbitcoin, given that several BIPs have been written by libbitcoin contributors as well (including this BIP1). But I would just drop this statement altogether. My mistake on the IRC, read too quickly.

btcdrak commented at 9:20 PM on January 1, 2016: contributor

@evoskuil I agree, drop the sentence entirely.

BIP1: remove line about committers

https://github.com/bitcoin/bips/pull/269#issuecomment-168335009

66224130f0

kanzure commented at 9:39 PM on January 1, 2016: contributor

@evoskuil @btcdrak removed in 66224130f03ffb94daae9692d1b8d25b1c35e6ba

evoskuil commented at 10:30 PM on January 1, 2016: contributor

@kanzure Change my NACK to ACK.

luke-jr added the label Proposed BIP modification on Jan 6, 2016

in bip-0001.mediawiki:None in 66224130f0

  23 | @@ -23,30 +24,26 @@ There are three kinds of BIP:
  24 |  
  25 |  ==BIP Work Flow==
  26 |  
  27 | -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]].
  28 | +The BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development & Technical Discussion] forum) is the best way to go about this.
  29 |  
  30 | -Authors MUST NOT self assign numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject.
  31 | +Vetting an idea publicly before going as far as writing a BIP is meant to both save the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need a BIP and can be injected into the relevant Bitcoin development work flow with a patch submission to the relevant Bitcoin issue tracker.

luke-jr commented at 6:24 PM on January 8, 2016:

to both save

Should be "to save both"

luke-jr merged this on Jan 8, 2016

luke-jr closed this on Jan 8, 2016

hypo-test referenced this in commit 507099dd0a on Nov 25, 2018