summaryrefslogtreecommitdiff
path: root/bip-0001.mediawiki
diff options
context:
space:
mode:
authorLuke Dashjr <luke-jr+git@utopios.org>2016-01-08 18:55:01 +0000
committerLuke Dashjr <luke-jr+git@utopios.org>2016-01-08 18:55:01 +0000
commit4c1c02a94dc19b79e372c57a9020a6bb14bfc737 (patch)
treed4a32b8a9d00d48649f732e18431f7f29085e9bf /bip-0001.mediawiki
parente3f3c6453d1e803c15ab53f118055c253bf5ab52 (diff)
downloadbips-4c1c02a94dc19b79e372c57a9020a6bb14bfc737.tar.xz
BIP 0001: Clarification of when changes don't need a BIP
Diffstat (limited to 'bip-0001.mediawiki')
-rw-r--r--bip-0001.mediawiki2
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index aac6ba4..e1abadd 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 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.
+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 standardisation between multiple projects; these don't need a BIP and should 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.