summaryrefslogtreecommitdiff
path: root/bip-0001.mediawiki
diff options
context:
space:
mode:
authorBryan Bishop <kanzure@gmail.com>2016-01-01 11:54:17 -0600
committerBryan Bishop <kanzure@gmail.com>2016-01-01 11:55:51 -0600
commite1628bb408f89769a99636c06ce9f440b8a2fda9 (patch)
tree97e91854d199e078ac45ea913279b28319015983 /bip-0001.mediawiki
parentea1111226f3c66c14f22d48ce0d1fb94ce85fd1f (diff)
downloadbips-e1628bb408f89769a99636c06ce9f440b8a2fda9.tar.xz
BIP1: use "relevant Bitcoin issue tracker" instead
Also, remove an unnecessarily duplicated sentence.
Diffstat (limited to 'bip-0001.mediawiki')
-rw-r--r--bip-0001.mediawiki4
1 files 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.