Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 74.125.82.182 as permitted sender)
	client-ip=74.125.82.182; envelope-from=jgarzik@bitpay.com;
	helo=mail-we0-f182.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAJHLa0MCJzFapBYu+cGcJobeVkuS3yibpgaEJOmEj5-1wWEDYA@mail.gmail.com>
References: <CAJHLa0MCJzFapBYu+cGcJobeVkuS3yibpgaEJOmEj5-1wWEDYA@mail.gmail.com>
Date: Mon, 21 Oct 2013 13:17:20 -0400
Message-ID: <CAJHLa0OOY30z96d7VgfD3fTznC=WK7+ZH6k8vr-DVNkqbGHtxA@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
Precedence: list

Added:  I'm happy with gmaxwell as BIP editor as well, as he is
apparently the current BIP-number-assigner-in-chief.  :)

The goal is to improve the process, hash-seal our specs, and create an
easy way for anyone with at least an email address to participate.

On Mon, Oct 21, 2013 at 10:30 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> This summarizes some rambling on IRC about revising the BIPS process.
>
> Right now, the BIPS process is a bit haphazard.  Previously, BIPS were
> in a git repo, and the BIPS on the wiki were locked against editing.
> The BIPS editor at the time started off well, but was eventually
> M.I.A.  So the BIPS "home" moved de facto to where everyone was
> reading them anyway, the wiki.  They were made editable, and it became
> easier to Just Pick A Number And Write One.  However, this inevitably
> became a bit disorganized.  Further, there was a recent incident --
> easily reverted -- where someone hopped on the wiki and started
> arbitrarily editing an existing standard.
>
> BIPs need to move back to git, in my opinion.  Standards should be
> hash-sealed against corruption.  Anything less would be uncivilized,
> and un-bitcoin.  However, many on IRC pointed out requiring a git pull
> request might be a burdensome process, and discourage some
> contributors.  The following is a sketch of an improved process.
>
> 1) BIP Draft.
>
> Modelled after IETF drafts.  Anybody may submit a BIP draft, as long
> as it meets two very loose requirements:
> * At least somewhat related to bitcoin.  Note, I did not say "crypto-currency".
> * Formatted similarly to existing BIPs (i.e. markdown, or whatever the
> community prefers)
>
> BIP drafts may be submitted via git pull request, or by emailing an
> attachment to bips.editor@bitcoin.org.  This mirrors the Linux kernel
> change submission process:  git is preferred, but there is always a
> non-git method for folks who cannot or do not wish to use git or
> github.
>
> BIP drafts are stored in git://github.com/bitcoin/bips.git/drafts/ and
> are not automatically assigned a BIPS number.
>
> 2) Time passes.  Software for BIP drafts is developed, tested,
> published, and publicly discussed in a typical open source manner.
>
> 3) If interest and use cases remain strong, a BIP number may be
> requested, and the BIP draft is moved to
> git://github.com/bitcoin/bips.git main directory.
>
> 4) If there is general consensus that the BIP should be adopted, the
> BIP status is changed to "accepted."
>
> There are no specified time limits.  Sometimes consensus about a BIP
> is reached in days, sometimes 12+ months or more.  It varies widely
> depending on the feature's complexity and impact.
>
> As with the IETF, it will be q
>
> --
> Jeff Garzik
> Senior Software Engineer and open source evangelist
> BitPay, Inc.      https://bitpay.com/


-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/