1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
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 <jgarzik@bitpay.com>) id 1VYGV3-00052I-UK
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Oct 2013 14:30:29 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.212.169 as permitted sender)
client-ip=209.85.212.169; envelope-from=jgarzik@bitpay.com;
helo=mail-wi0-f169.google.com;
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VYGV2-00077z-Ra
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Oct 2013 14:30:29 +0000
Received: by mail-wi0-f169.google.com with SMTP id cb5so5277333wib.0
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Oct 2013 07:30:22 -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:date:message-id:subject:from:to
:content-type;
bh=gd2iSlkBcRqF5P7JIWde75NkpfDuDt55wuxTTGN9Ut0=;
b=mi59p0RuvRB0uD8cWY4DnvHe72ONodrZMQ7ciB5PS2WM0z0zrn8ciJ99rKaDuxqeCH
Yqasp6aNeCXFbuj9BwleTQ9jLL6rjclM3BK6nLg5UGnZVuqxmHZrMPIj/ee4AYs9oGXx
K50vc2OfImzsD/GSwwMHMsKkHxWvml2/1mBav19qPV0J+CyGCm1UUVcqOZy8QKpvSF8j
1WPL64g/Aa/Qf5tHwN23JufpMcxHOaMIhJtrmkOzgS4JKC9PsSFA13ZgrzYEX655nDBh
TTwHUkKCX6gJq+ntnD+/V0Szh1J83+5EURfxZ8fxKuZ+L6LhvTrHzVdMQFWUVGJDhSxi
N5nQ==
X-Gm-Message-State: ALoCoQliA9VMOyKjPAzVONJN5uscc4ZYnkbFawb0XojpuMmV8QaztoJyy0vXT0dX8fDDkxHHt2Ns
MIME-Version: 1.0
X-Received: by 10.194.174.36 with SMTP id bp4mr13660215wjc.7.1382365822574;
Mon, 21 Oct 2013 07:30:22 -0700 (PDT)
Received: by 10.194.164.164 with HTTP; Mon, 21 Oct 2013 07:30:22 -0700 (PDT)
Date: Mon, 21 Oct 2013 10:30:22 -0400
Message-ID: <CAJHLa0MCJzFapBYu+cGcJobeVkuS3yibpgaEJOmEj5-1wWEDYA@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
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: 1VYGV2-00077z-Ra
Subject: [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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 21 Oct 2013 14:30:30 -0000
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/
|
