summaryrefslogtreecommitdiff
path: root/24/22bb4bddd268a319ed9c5feb61aebe167bde48
blob: 23d44beb7006eef98006f1df8769e10118e069b8 (plain)
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
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
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 <drak@zikula.org>) id 1Viomn-0007qC-Ah
	for bitcoin-development@lists.sourceforge.net;
	Tue, 19 Nov 2013 17:08:25 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of zikula.org
	designates 74.125.82.182 as permitted sender)
	client-ip=74.125.82.182; envelope-from=drak@zikula.org;
	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 1Viomm-0000lc-EK
	for bitcoin-development@lists.sourceforge.net;
	Tue, 19 Nov 2013 17:08:25 +0000
Received: by mail-we0-f182.google.com with SMTP id q59so6021688wes.13
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 19 Nov 2013 09:08:18 -0800 (PST)
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:from:date
	:message-id:subject:to:cc:content-type;
	bh=iphKFhlADaWjQZzYHmRyWfC322IhstITu5NI05wRmc8=;
	b=IbEpyswxK7XlJjgBJw9sKYjuqxMcBW27zQqFxnZujYHr249JLZAa/QzPu0dPonYCdw
	r1EatauTeV+f/L1H7F/5MZSWRpu1fpocuCE6zQcrKRbVPyXAq7pEyn3K4bzUpw/YVrct
	fXCk/WIZ8BU+/J2c1ff5ylKicJqz9z2xTEh0npfX3acfzMH658rpgCEJhg7O1iiQWi4W
	eCh2kSSl/7lh8Xf9jMcJy/VdDVBAAovMFhUHlylJFREdqf8cN1hd5p3S47R4pLT4VdUd
	7bDRIDMtaqOrW8wLE2yw/PieWOOsLKbzHrSdCTS0IUogTuAv2NDShEZiHD5p8OoVKah5
	Rk8g==
X-Gm-Message-State: ALoCoQmV37rF5zhdW0qMnfez908VPei6vyIIiwVDX0qZNWAO3YFW/1ZcYQ4ul/hDOVJESAFEpByx
X-Received: by 10.194.20.202 with SMTP id p10mr2822470wje.39.1384880898174;
	Tue, 19 Nov 2013 09:08:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.93.105 with HTTP; Tue, 19 Nov 2013 09:07:58 -0800 (PST)
In-Reply-To: <CAAS2fgREw+5NWaFVYd9FS-s63_-24tyWsz5_w6yc8+mGnFYUgQ@mail.gmail.com>
References: <CAJHLa0MCJzFapBYu+cGcJobeVkuS3yibpgaEJOmEj5-1wWEDYA@mail.gmail.com>
	<CA+s+GJDnCx4ZT5woovB-MsKfHOqNoC9WefKQ-VMpWHCZrat5Kw@mail.gmail.com>
	<CANAnSg1eH8+sY6n4-cptdzS5Qj0aXdN_d8h8B9joyk73HGL6ZA@mail.gmail.com>
	<CAAS2fgREw+5NWaFVYd9FS-s63_-24tyWsz5_w6yc8+mGnFYUgQ@mail.gmail.com>
From: Drak <drak@zikula.org>
Date: Tue, 19 Nov 2013 17:07:58 +0000
Message-ID: <CANAnSg18FWEQqfqMMY_3XYeLcZ0NJN_1S5QaR0mbp34ZHqM0hg@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b5d9657fe03fa04eb8ab5f0
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-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.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: zikula.org]
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Viomm-0000lc-EK
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <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: Tue, 19 Nov 2013 17:08:25 -0000

--047d7b5d9657fe03fa04eb8ab5f0
Content-Type: text/plain; charset=UTF-8

On 19 November 2013 17:01, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Tue, Nov 19, 2013 at 8:53 AM, Drak <drak@zikula.org> wrote:
> > It's quite normal for standards bodies to allocate numbers when in draft
> > status. If they don't pass, they don't pass - they are clearly labelled
> > DRAFTs.
> >
> > +1 on having things in a github repository. Much better for
> collaboration,
>
> The IETF makes a clear distinction between individual proposals and
> documents which have been accepted by a working group. The former are
> named after their authors.  Work is not assigned a number until it is
> complete.
>
> I believe it is important to distinguish complete work that people
> should be implementing from things which are incomplete,  and even
> more important to distinguish the work of single parties.
>
> Otherwise you're going to get crap like BIP90: "Increase the supply of
> Bitcoins to 210 million" being confused as an earnest proposal
> supported by many that has traction.
>

I wasnt suggesting people add drafts willy nilly to the repository.
When working on a proposal you can work on it in your own fork and create a
PR. When it's ready to be accepted as a working draft by the WG, then it
can be merged into the draft folder. At which point, PRs are made to that
draft copy until it gets into a ready state to become final. If passed,
it's moved to the accepted/ folder.

This way random BIPS cannot be added to the drafts/ folder in the official
repo. They are only added once they are accepted as a working draft
proposal by Gavin or whatever. Now you get all the niceties of github
workflow for collaboration and tweaking of the draft proposal.

Drak

--047d7b5d9657fe03fa04eb8ab5f0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
9 November 2013 17:01, Gregory Maxwell <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>&gt;</span>=
 wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Nov 19, 2013 at 8:=
53 AM, Drak &lt;<a href=3D"mailto:drak@zikula.org">drak@zikula.org</a>&gt; =
wrote:<br>


&gt; It&#39;s quite normal for standards bodies to allocate numbers when in=
 draft<br>
&gt; status. If they don&#39;t pass, they don&#39;t pass - they are clearly=
 labelled<br>
&gt; DRAFTs.<br>
&gt;<br>
&gt; +1 on having things in a github repository. Much better for collaborat=
ion,<br>
<br>
</div>The IETF makes a clear distinction between individual proposals and<b=
r>
documents which have been accepted by a working group. The former are<br>
named after their authors. =C2=A0Work is not assigned a number until it is<=
br>
complete.<br>
<br>
I believe it is important to distinguish complete work that people<br>
should be implementing from things which are incomplete, =C2=A0and even<br>
more important to distinguish the work of single parties.<br>
<br>
Otherwise you&#39;re going to get crap like BIP90: &quot;Increase the suppl=
y of<br>
Bitcoins to 210 million&quot; being confused as an earnest proposal<br>
supported by many that has traction.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">I wasnt suggesting =
people add drafts willy nilly to the repository.</div><div class=3D"gmail_e=
xtra">When working on a proposal you can work on it in your own fork and cr=
eate a PR. When it&#39;s ready to be accepted as a working draft by the WG,=
 then it can be merged into the draft folder. At which point, PRs are made =
to that draft copy until it gets into a ready state to become final. If pas=
sed, it&#39;s moved to the accepted/ folder.</div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This way ra=
ndom BIPS cannot be added to the drafts/ folder in the official repo. They =
are only added once they are accepted as a working draft proposal by Gavin =
or whatever. Now you get all the niceties of github workflow for collaborat=
ion and tweaking of the draft proposal.</div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Drak<br></d=
iv><div class=3D"gmail_extra"><br></div></div>

--047d7b5d9657fe03fa04eb8ab5f0--