Update BIP-0001 for github move

- Mention github instead of wiki
- Add markdown as allowed format
- Fix some weirdnesses such as "A BIP editor must subscribe to the
  gmaxwell@gmail.com list.". Remove the repetition and create a new
  section which lists the BIP editors (currently only gmaxwell).
- Prefer discussion on mailing list to forum

1 files changed, 19 insertions, 14 deletions

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index 3661daf..adfa60d 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -24,25 +24,25 @@ 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 gmaxwell@gmail.com (no cross-posting please). Also see BIP Editor Responsibilities & Workflow below.
+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. 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.
 
-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://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum or the [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net] mailing list is the best way to go about this.
+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 [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net] 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 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.
 
 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 [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net]. 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.
 
-Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors gmaxwell@gmail.com. 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.
+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.
 
-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 create and create a page for it on the [[Bitcoin_Improvement_Proposals|Bitcoin Wiki]]. 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 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.
 
-The BIP author may update the Draft as necessary on the wiki.
+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, etc. BIP authors should use their discretion here.
+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.
 
@@ -70,7 +70,7 @@ Each BIP should have the following parts:
 
 * Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License.
 
-* Specification -- The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin).
+* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin).
 
 * Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the BIP solves. BIP submissions without sufficient motivation may be rejected outright.
 
@@ -86,7 +86,7 @@ Each BIP should have the following parts:
 
 ==BIP Formats and Templates==
 
-BIPs should be written in mediawiki wiki syntax. Image files should be included in the current subdirectory for that BIP.
+BIPs should be written in mediawiki or markdown format. Image files should be included in a subdirectory for that BIP.
 
 ==BIP Header Preamble==
 
@@ -138,10 +138,15 @@ BIPs may include auxiliary files such as diagrams. Such files must be named BIP-
 
 It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.
 
-If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor gmaxwell@gmail.com. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
-BIP Editor Responsibilities & Workflow
+If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
 
-A BIP editor must subscribe to the gmaxwell@gmail.com list. All BIP-related correspondence should be sent (or CC'd) to gmaxwell@gmail.com (but please do not cross-post!).
+==BIP Editors==
+
+The current BIP editor is Gregory Maxwell who can be contacted at [[mailto:gmaxwell@gmail.com|gmaxwell@gmail.com]].
+
+==BIP Editor Responsibilities & Workflow==
+
+A BIP editor must subscribe to the Bitcoin development mailing list. All BIP-related correspondence should be sent (or CC'd) to gmaxwell@gmail.com.
 
 For each new BIP that comes in an editor does the following:
 
@@ -155,9 +160,9 @@ Once the BIP is ready for the repository, the BIP editor will:
 
 * Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141).
 
-* List the BIP in BIP 0 (in two places: the categorized list, and the numeric list).
+* Add the BIP to the [https://github.com/bitcoin/bips bitcoin/bips] repository on GitHub.
 
-* Add the BIP to the wiki.
+* List the BIP in [[README.mediawiki]]
 
 * Send email back to the BIP author with next steps (post to bitcoin mailing list).
 
@@ -167,4 +172,4 @@ The editors don't pass judgement on BIPs. We merely do the administrative & edit
 
 ==History==
 
-This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the Bitcoin editors or the forums at bitcointalk.org.
+This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the BIP editors or the Bitcoin development mailing list.