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
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C7AB5F6C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Feb 2016 16:00:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com
[209.85.214.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CA0F3170
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Feb 2016 16:00:03 +0000 (UTC)
Received: by mail-ob0-f169.google.com with SMTP id wb13so120335121obb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 02 Feb 2016 08:00:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=G4IAc1t1BX8/uwzG54ovDqcUhrPjI6pVYvuydJ8HMBM=;
b=KE3yxKMbrTf1SbcG2pXVhi8H2nDq3eSdAXnHPW7Y1cifypRJmzY4MXjV0aC+KO/b6z
A6tLKx2GkArJzM2lKey0rElzn/UCERdDNhppIUd2YQQho2Xr2HRZGzwMSFe/oSlvGyy3
W1CVF5qyuX5A7mnY4JJXxz2M7Lu5MbiXN1K6IzoyX4ttu++E95gd9/jSAqSZD+d0jWPh
LRLyxffdTj/hmNHapIfewDkcjIRJNiExnDQuoQWAl1QreNCu7im66XXN7d5Pvg6PHsbe
fIYAorkVwlRgFuQGJelsLGC5XVKoinK7JJbTFpsA8HSHNNygq32vh0TGhNYvoDgkUJg3
pBIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=G4IAc1t1BX8/uwzG54ovDqcUhrPjI6pVYvuydJ8HMBM=;
b=R1ylK+aqnQvDy4X60B8lTm0AuLuSFDDVdWY0mp5r/ARPTyDzxAQP7jX1Ckgbp1hwSh
+Ze3fkUi7yYQRjV6gggYVU058k87qF6xRsye5A6ktHL2knAveSTBM0IZSBplJg+JV0wd
BbXCVvvZRUz1gV1XwyuitNhFPwmNuloTODrV1ynDQdhkDwVFx7oOej9YA3BHlNS9eHIN
rCDwvYQtlz97l8byaHdxGTqDBKYD1LRpfZCmiMZ612eCadJ7gT1BtpyJUax2K7tBtxVs
mt3YzdHUIvNvdsklzft1zuebSoyCZWcy3mMsQjpxstsd54tNWMLt6ZRd6FVqdIftsDo5
H8Bw==
X-Gm-Message-State: AG10YOR0Ejq/X6hhhA20R3jRdC8UErZNGLFsman7eoXRvYpj+AVSUOKFqUQNehR0UxVz4LqI8bdPyo1QBVfqzQ==
MIME-Version: 1.0
X-Received: by 10.60.116.35 with SMTP id jt3mr1402191oeb.57.1454428803097;
Tue, 02 Feb 2016 08:00:03 -0800 (PST)
Sender: dscotese@gmail.com
Received: by 10.60.55.71 with HTTP; Tue, 2 Feb 2016 08:00:03 -0800 (PST)
In-Reply-To: <201602020754.31734.luke@dashjr.org>
References: <201602012253.18009.luke@dashjr.org>
<CAGLBAhffm+1m=DAph-ac8mA9ytLpKqTT45XG1r6UFGFoUvJ+PA@mail.gmail.com>
<201602020754.31734.luke@dashjr.org>
Date: Tue, 2 Feb 2016 08:00:03 -0800
X-Google-Sender-Auth: ENQCIyyWD-bi6PQ-4E6L65fgpoY
Message-ID: <CAGLBAhfWj6YfnDPtXg4qaD_1hQtHK26_yP7hF1pbH8XNsYta8w@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=089e0117704928ec29052acb9862
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,URIBL_SBL
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 02 Feb 2016 17:29:33 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Process: Status, comments,
and copyright licenses
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2016 16:00:04 -0000
--089e0117704928ec29052acb9862
Content-Type: text/plain; charset=UTF-8
On Mon, Feb 1, 2016 at 11:54 PM, Luke Dashjr <luke@dashjr.org> wrote:
> On Tuesday, February 02, 2016 5:50:29 AM Dave Scotese wrote:
> > The section that starts "Should two software projects need to release"
> > addresses issues that are difficult to ascertain from what is written
> > there. I'll take a stab at what it means:
> >
> > Would bitcoin be better off if multiple applications provided their own
> > implementations of API/RPC and corresponding application layer BIPs?
> >
> > - While there is only one such application, its UI will be the obvious
> > standard and confusion in usability will be avoided.
> > - Any more than a single such application will benefit from the
> > coordination encouraged and aided by this BIP and BIP 123.
>
> The original question is intended to answer both: a) why only one
> implementation is insufficient for Final status, and b) why two is
> sufficient.
>
> If every application had its own BIP (how I understand your version), none
> of
> them would be standards and it wouldn't make sense to have a BIP at all -
> just
> project documentation would be sufficient.
>
> > "To avoid doubt: comments and status are unrelated metrics to judge a
> BIP,
> > and neither should be directly influencing the other." makes more sense
> to
> > me as "To avoid doubt: comments and status are intended to be unrelated
> > metrics. Any influence of one over the other indicates a deviation from
> > their intended use." This can be expanded with a simple example: "In
> other
> > words, a BIP having the status 'Rejected' is no reason not to write
> > additional comments about it. Likewise, overwhelming support for a BIP
> in
> > its comments section doesn't change the requirements for the 'Accepted'
> or
> > 'Active' status."
>
> Extending this to "influence" is probably too far - after all, comments may
> discourage implementations, which can very well result in the Status
> eventually becoming Rejected rather than Final. How about:
>
> "To avoid doubt: comments and status are intended to be unrelated metrics.
> In
> other words, a BIP having the status 'Rejected' is no reason to write (or
> not
> write) additional comments about it, nor would a status of 'Final' preclude
> comments discouraging [further] implementation. Likewise, overwhelming
> support
> for a BIP in its comments section doesn't change the requirements for the
> 'Final' or 'Active' status."
>
Yes, that is much better. The mention of "only one is insufficient" and
"two are sufficient" in the bullets clarifies them well too.
>
> > Since the Bitcoin Wiki can be updated with comments from other places, I
> > think the author of a BIP should be allowed to specify other Internet
> > locations for comments. So "link to a Bitcoin Wiki page" could instead
> be
> > "link to a comments page (strongly recommended to be in the Bitcoin
> > Wiki)".
>
> Hmm, I wonder if this could be too easily abuse to discourage comments
> (because the commenter does not wish to register with yet another forum),
> and/or censor negative comments (because the author has made his own forum
> specifically for the purpose).
>
BIP acceptance hinges on accessibility and discussion. Wherever discussion
happens, someone can mention the Wiki page they created to sidestep such an
unfortunate abuse. I have always been in favor of allowing people to do
stupid things simply because that helps them learn not to do them. The
result is often some (at least slight) embarrassment of the bad actor and a
lesson for everyone paying attention. The censorship of BitcoinXT
discussion had this effect and has softened the enthusiasm many had for...
let's call it: guarding against their own cognitive dissonance through
censorship and intimidation.
In fact this last item is probably what raised a flag for me when thinking
about the specification that they should "link to a Bitcoin Wiki page with
a summary tone of the comments." I have too often seen great discussions of
controversy lose a lot of valuable input because they lived in an
environment controlled by someone who let bias infect their moderation
decisions. I know that even I might do that, so encouraging others to have
access to my competitors feels right.
--089e0117704928ec29052acb9862
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Feb 1, 2016 at 11:54 PM, Luke Dashjr <span dir=3D"ltr"><<a h=
ref=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span clas=
s=3D"">On Tuesday, February 02, 2016 5:50:29 AM Dave Scotese wrote:<br>
> The section that starts "Should two software projects need to rel=
ease"<br>
> addresses issues that are difficult to ascertain from what is written<=
br>
> there.=C2=A0 I'll take a stab at what it means:<br>
><br>
> Would bitcoin be better off if multiple applications provided their ow=
n<br>
> implementations of API/RPC and corresponding application layer BIPs?<b=
r>
><br>
</span>>=C2=A0 =C2=A0 - While there is only one such application, its UI=
will be the obvious<br>
<span class=3D"">>=C2=A0 =C2=A0 standard and confusion in usability will=
be avoided.<br>
</span>>=C2=A0 =C2=A0 - Any more than a single such application will ben=
efit from the<br>
<span class=3D"">>=C2=A0 =C2=A0 coordination encouraged and aided by thi=
s BIP and BIP 123.<br>
<br>
</span>The original question is intended to answer both: a) why only one<br=
>
implementation is insufficient for Final status, and b) why two is sufficie=
nt.<br>
<br>
If every application had its own BIP (how I understand your version), none =
of<br>
them would be standards and it wouldn't make sense to have a BIP at all=
- just<br>
project documentation would be sufficient.<br>
<span class=3D""><br>
> "To avoid doubt: comments and status are unrelated metrics to jud=
ge a BIP,<br>
> and neither should be directly influencing the other." makes more=
sense to<br>
> me as "To avoid doubt: comments and status are intended to be unr=
elated<br>
> metrics. Any influence of one over the other indicates a deviation fro=
m<br>
> their intended use."=C2=A0 This can be expanded with a simple exa=
mple: "In other<br>
> words, a BIP having=C2=A0 the status 'Rejected' is no reason n=
ot to write<br>
> additional comments about it.=C2=A0 Likewise, overwhelming support for=
a BIP in<br>
> its comments section doesn't change the requirements for the '=
Accepted' or<br>
> 'Active' status."<br>
<br>
</span>Extending this to "influence" is probably too far - after =
all, comments may<br>
discourage implementations, which can very well result in the Status<br>
eventually becoming Rejected rather than Final. How about:<br>
<br>
"To avoid doubt: comments and status are intended to be unrelated metr=
ics. In<br>
other words, a BIP having the status 'Rejected' is no reason to wri=
te (or not<br>
write) additional comments about it, nor would a status of 'Final' =
preclude<br>
comments discouraging [further] implementation. Likewise, overwhelming supp=
ort<br>
<span class=3D"">for a BIP in its comments section doesn't change the r=
equirements for the<br>
</span>'Final' or 'Active' status."<br></blockquote><d=
iv><br></div><div>Yes, that is much better.=C2=A0 The mention of "only=
one is insufficient" and "two are sufficient" in the bullet=
s clarifies them well too.<br>=C2=A0<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
<span class=3D""><br>
> Since the Bitcoin Wiki can be updated with comments from other places,=
I<br>
> think the author of a BIP should be allowed to specify other Internet<=
br>
> locations for comments.=C2=A0 So "link to a Bitcoin Wiki page&quo=
t; could instead be<br>
> "link to a comments page (strongly recommended to be in the Bitco=
in<br>
> Wiki)".<br>
<br>
</span>Hmm, I wonder if this could be too easily abuse to discourage commen=
ts<br>
(because the commenter does not wish to register with yet another forum),<b=
r>
and/or censor negative comments (because the author has made his own forum<=
br>
specifically for the purpose).<br></blockquote><div><br></div><div>BIP acce=
ptance hinges on accessibility and discussion.=C2=A0 Wherever discussion ha=
ppens, someone can mention the Wiki page they created to sidestep such an u=
nfortunate abuse.=C2=A0 I have always been in favor of allowing people to d=
o stupid things simply because that helps them learn not to do them.=C2=A0 =
The result is often some (at least slight) embarrassment of the bad actor a=
nd a lesson for everyone paying attention.=C2=A0 The censorship of BitcoinX=
T discussion had this effect and has softened the enthusiasm many had for..=
. let's call it: guarding against their own cognitive dissonance throug=
h censorship and intimidation.<br></div><div><br></div><div>In fact this la=
st item is probably what raised a flag for me when thinking about the speci=
fication that they should "link to a Bitcoin Wiki page with a summary =
tone of the comments." I have too often seen great discussions of cont=
roversy lose a lot of valuable input because they lived in an environment c=
ontrolled by someone who let bias infect their moderation decisions.=C2=A0 =
I know that even I might do that, so encouraging others to have access to m=
y competitors feels right.<br></div></div><br></div></div>
--089e0117704928ec29052acb9862--
|