From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VYJ6d-0006Af-R5 for bitcoin-development@lists.sourceforge.net; Mon, 21 Oct 2013 17:17:27 +0000 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; Received: from mail-we0-f182.google.com ([74.125.82.182]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VYJ6c-00016a-Cz for bitcoin-development@lists.sourceforge.net; Mon, 21 Oct 2013 17:17:27 +0000 Received: by mail-we0-f182.google.com with SMTP id t61so6850523wes.41 for ; Mon, 21 Oct 2013 10:17:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=sdwsGuZUfiecAHuv3U/VzaGDuz//vwPNIB8wS6mb6OI=; b=PDWIvQvWAh1CZKoKwXhe5Rladqy/CF1qnO5g7EZMgMZS7vHuDtNh9uF4+yonTkKpHc L7af7oqWuxLYzJtMKyQ05eHamRI33h6mnEZq+PUPFnuNQkK+oguVlFlBmSQeGmnrfdG9 jriF8NIthtqn9BgTGc+Ge2isfta5/Uvw7DR7E9EDW1L+FVTvmNShizTMFJE5AWVVcACV KM4Wkwr+HDAGe+SNMeZS3ov6ilqgOzdSLmhFUkr6soZFx0bWLbn/C+cxIQL/R7U3//4K N/od7gtu+1Ln1IX8INpJRjhorUkM0ZPeEKMHA3+FiZIryJrmAmpwzWh9wcVH/1I8icEE OWRg== X-Gm-Message-State: ALoCoQm9lacoFvZtKHmgc9B4nNvwCxlEv6+EcwXpuZOtCVP/NwJJS+GbWxDTD6eD33zYWQDlogXP MIME-Version: 1.0 X-Received: by 10.194.11.38 with SMTP id n6mr14971746wjb.25.1382375840206; Mon, 21 Oct 2013 10:17:20 -0700 (PDT) Received: by 10.194.164.164 with HTTP; Mon, 21 Oct 2013 10:17:20 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Oct 2013 13:17:20 -0400 Message-ID: From: Jeff Garzik To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: github.com] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VYJ6c-00016a-Cz Subject: Re: [Bitcoin-development] Revisiting the BIPS process, a proposal X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:17:28 -0000 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 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/