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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <milly@bitcoins.info>) id 1Z5blu-0001Tq-56
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 15:30:30 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitcoins.info
designates 70.90.2.18 as permitted sender) client-ip=70.90.2.18;
envelope-from=milly@bitcoins.info; helo=mail.help.org;
Received: from mail.help.org ([70.90.2.18])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1Z5blo-0003BP-Gt
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 15:30:30 +0000
Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA
; Thu, 18 Jun 2015 11:30:16 -0400
Message-ID: <5582E3FE.7010206@bitcoins.info>
Date: Thu, 18 Jun 2015 11:30:06 -0400
From: Milly Bitcoin <milly@bitcoins.info>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <55828737.6000007@riseup.net> <CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com> <20150618111407.GA6690@amethyst.visucore.com> <CANEZrP2iMXeL-5zyE2cvoyNRakhZbQfLXORZ2AhqEATQE-KjAQ@mail.gmail.com>
<CAOG=w-sWimZTJe=4gCvC5R7SAEK+Nvo-hZtM7xC-bBQd0pG3mw@mail.gmail.com>
In-Reply-To: <CAOG=w-sWimZTJe=4gCvC5R7SAEK+Nvo-hZtM7xC-bBQd0pG3mw@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------090909030505000901020501"
X-Spam-Score: -1.0 (-)
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
1.0 HTML_MESSAGE BODY: HTML included in message
-0.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z5blo-0003BP-Gt
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer
to Remove Commit Access from Other Developers
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: Thu, 18 Jun 2015 15:30:30 -0000
This is a multi-part message in MIME format.
--------------090909030505000901020501
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
On 6/18/2015 11:03 AM, Mark Friedenbach wrote:
> On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn <mike@plan99.net
> <mailto:mike@plan99.net>> wrote:
>
> The first issue is how are decisions made in Bitcoin Core? I
> struggle to explain this to others because I don't understand it
> myself. Is it a vote of people with commit access? Is it a 100%
> agreement of "core developers" and if so, who are these people? Is
> it "whoever reverts the change last"? Could I write down in a
> document a precise description of how decisions are made? No, and
> that's been a fairly frustrating problem for a long time.
>
>
> There is a quote from United States Supreme Court Justice Potter
> Stewart to describe his threshold test for obscenity which is relevant
> here: "I know it when I see it."
>
> It is hard certainly, and perhaps even impossible to write down a
> system of rules that is used to resolve every dispute among core
> developers. But that doesn't mean it isn't obvious to all the
> participants what is going on. If a contentious change is proposed,
> and if after sufficient debate there are still members of the
> technical community with reasoned, comprehensible objections who are
> not merely being obstinate in the views -- a neutral observer would
> agree that their concerns have not been met -- then there is a lack of
> consensus.
>
> If there was some sort of formal process however, the system wouldn't
> work. Rules can be gamed, and if you add rules to a process then that
> process can be gamed. Instead we all have a reasonable understanding
> of what "technical consensus" is, and we all know it when we see it.
> Where we do not see it, we do not proceed.
>
There is always a process. Right now the process is haphazard, unclear,
and constantly changing without being written down so people don't
actually know what it is. In fact you do not all have a reasonable
understanding of "technical consensus" because if you did then you could
write it down ... but you can't. The current process is being gamed by
people making tweets, reddit posts, videos, and blog posts. A more
formalized process would channel that activity into a a more usable format.
This kind of thing always happens as projects become larger and more
diverse. Something that was once a small group turns into a big group
of diverse stakeholders. When it gets too big for the informal
processes then some people get upset and defensive. Happens all the time
but it is not really a good excuse to keep doing things in an
inefficient manner. The old ways just don't scale and if you ever
worked on massive projects then you know these formal processes work better.
Russ
--------------090909030505000901020501
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 6/18/2015 11:03 AM, Mark Friedenbach
wrote:<br>
</div>
<blockquote
cite="mid:CAOG=w-sWimZTJe=4gCvC5R7SAEK+Nvo-hZtM7xC-bBQd0pG3mw@mail.gmail.com"
type="cite">
<div dir="ltr">On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">The first issue is how are
decisions made in Bitcoin Core? I struggle to
explain this to others because I don't understand it
myself. Is it a vote of people with commit access?
Is it a 100% agreement of "core developers" and if
so, who are these people? Is it "whoever reverts the
change last"? Could I write down in a document a
precise description of how decisions are made? No,
and that's been a fairly frustrating problem for a
long time.<br>
</div>
</div>
</div>
</blockquote>
<div><br>
There is a quote from United States Supreme Court Justice
Potter Stewart to describe his threshold test for
obscenity which is relevant here: "I know it when I see
it."<br>
<br>
</div>
<div>It is hard certainly, and perhaps even impossible to
write down a system of rules that is used to resolve every
dispute among core developers. But that doesn't mean it
isn't obvious to all the participants what is going on. If
a contentious change is proposed, and if after sufficient
debate there are still members of the technical community
with reasoned, comprehensible objections who are not
merely being obstinate in the views -- a neutral observer
would agree that their concerns have not been met -- then
there is a lack of consensus.<br>
<br>
</div>
<div>If there was some sort of formal process however, the
system wouldn't work. Rules can be gamed, and if you add
rules to a process then that process can be gamed. Instead
we all have a reasonable understanding of what "technical
consensus" is, and we all know it when we see it. Where we
do not see it, we do not proceed.<br>
</div>
</div>
</div>
</div>
<br>
</blockquote>
<br>
There is always a process. Right now the process is haphazard,
unclear, and constantly changing without being written down so
people don't actually know what it is. In fact you do not all have
a reasonable understanding of "technical consensus" because if you
did then you could write it down ... but you can't. The current
process is being gamed by people making tweets, reddit posts,
videos, and blog posts. A more formalized process would channel
that activity into a a more usable format. <br>
<br>
This kind of thing always happens as projects become larger and more
diverse. Something that was once a small group turns into a big
group of diverse stakeholders. When it gets too big for the
informal processes then some people get upset and defensive.
Happens all the time but it is not really a good excuse to keep
doing things in an inefficient manner. The old ways just don't
scale and if you ever worked on massive projects then you know these
formal processes work better.<br>
<br>
Russ<br>
<br>
<br>
</body>
</html>
--------------090909030505000901020501--
|
