From bada79afddc7cd70f7ad36d163aa7110964e03ee Mon Sep 17 00:00:00 2001 From: Bryan Bishop Date: Fri, 1 Jan 2016 11:04:23 -0600 Subject: BIP1: trivial formatting change --- bip-0001.mediawiki | 1 + 1 file changed, 1 insertion(+) diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index faa8029..ad96dce 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -13,6 +13,7 @@ BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providin We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. + ==BIP Types== There are three kinds of BIP: -- cgit v1.2.3 From c1261ac6473040ca6079fe4f9301102d0e518446 Mon Sep 17 00:00:00 2001 From: Bryan Bishop Date: Fri, 1 Jan 2016 11:06:47 -0600 Subject: 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. --- bip-0001.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index ad96dce..9703409 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -28,7 +28,7 @@ The BIP editors assign BIP numbers and change their status. Please send all BIP- 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. -The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones. +The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. 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. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones. 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. -- cgit v1.2.3 From ea1111226f3c66c14f22d48ce0d1fb94ce85fd1f Mon Sep 17 00:00:00 2001 From: Bryan Bishop Date: Fri, 1 Jan 2016 11:32:55 -0600 Subject: 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. --- bip-0001.mediawiki | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index 9703409..41b3f61 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -24,30 +24,26 @@ There are three kinds of BIP: ==BIP Work Flow== -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]]. +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. -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. +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 Bitcoin Core development work flow with a patch submission to the Bitcoin Core issue tracker. -The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. 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. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones. +Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. -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. +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. -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. +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. -Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal. +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]]. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. -Following a discussion, the proposal should be sent to the Bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. +Authors MUST NOT self assign BIP numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject. -If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. +If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the BIPs git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. 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. The BIP author may update the Draft as necessary in the git repository. Updates to drafts may also be submitted by the author as pull requests. Standards Track BIPs consist of two parts, a design document and a reference implementation. The BIP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the BIP. Standards Track BIPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final. -BIP authors are responsible for collecting community feedback on a 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. - -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. - Once a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final". A BIP can also be assigned status "Deferred". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status. @@ -168,11 +164,11 @@ The BIP editor will: * List the BIP in [[README.mediawiki]] -* Send email back to the BIP author with next steps (post to bitcoin mailing list). +* Send email back to the BIP author with next steps (post to bitcoin-dev mailing list). -Many BIPs are written and maintained by developers with write access to the Bitcoin codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. +Many BIPs are written and maintained by developers with write access to the Bitcoin Core codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. -The editors don't pass judgement on BIPs. We merely do the administrative & editorial part. Except for times like this, there's relatively low volume. +The BIP editors are intended to fulfill administrative and editorial responsibilities. ==History== @@ -181,3 +177,4 @@ This document was derived heavily from Python's PEP-0001. In many places text wa ==Changelog== 10 Oct 2015 - Added clarifications about sumission process and BIP number assignment. +01 Jan 2016 - Clarified early stages of BIP idea championing, collecting community feedback, etc. -- cgit v1.2.3 From e1628bb408f89769a99636c06ce9f440b8a2fda9 Mon Sep 17 00:00:00 2001 From: Bryan Bishop Date: Fri, 1 Jan 2016 11:54:17 -0600 Subject: BIP1: use "relevant Bitcoin issue tracker" instead Also, remove an unnecessarily duplicated sentence. --- bip-0001.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index 41b3f61..6d5a896 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -26,13 +26,13 @@ There are three kinds of BIP: 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. -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 Bitcoin Core development work flow with a patch submission to the Bitcoin Core issue tracker. +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. Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. 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. -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. +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. If in doubt, split your BIP into several well-focused ones. 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]]. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. -- cgit v1.2.3 From 17dda103e950db9c7c1e2e3e40ba0fc38535fdc0 Mon Sep 17 00:00:00 2001 From: Bryan Bishop Date: Fri, 1 Jan 2016 11:57:55 -0600 Subject: BIP1: fix changelog formatting --- bip-0001.mediawiki | 1 + 1 file changed, 1 insertion(+) diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index 6d5a896..7529479 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -177,4 +177,5 @@ This document was derived heavily from Python's PEP-0001. In many places text wa ==Changelog== 10 Oct 2015 - Added clarifications about sumission process and BIP number assignment. + 01 Jan 2016 - Clarified early stages of BIP idea championing, collecting community feedback, etc. -- cgit v1.2.3 From 66224130f03ffb94daae9692d1b8d25b1c35e6ba Mon Sep 17 00:00:00 2001 From: Bryan Bishop Date: Fri, 1 Jan 2016 15:37:47 -0600 Subject: BIP1: remove line about committers https://github.com/bitcoin/bips/pull/269#issuecomment-168335009 --- bip-0001.mediawiki | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index 7529479..8512b76 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -166,9 +166,7 @@ The BIP editor will: * Send email back to the BIP author with next steps (post to bitcoin-dev mailing list). -Many BIPs are written and maintained by developers with write access to the Bitcoin Core codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. - -The BIP editors are intended to fulfill administrative and editorial responsibilities. +The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. ==History== -- cgit v1.2.3 From ceb4f76df7f989e3fc6aece14fa55cd3f8fe7419 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Fri, 8 Jan 2016 18:52:25 +0000 Subject: BIP 0001: Minor language nit --- bip-0001.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index 8512b76..dbc6e04 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -26,7 +26,7 @@ There are three kinds of BIP: 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. -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. +Vetting an idea publicly before going as far as writing a BIP is meant to save both 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 applicable Bitcoin issue tracker. Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. -- cgit v1.2.3