summaryrefslogtreecommitdiff
path: root/5e/405d4bf11c82a9cbdc362b866fa990021ab12d
blob: 16bf50c7b93efd968b93ec414e564b0d24504086 (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
Return-Path: <milly@bitcoins.info>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3B95AAC1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 25 Jun 2015 04:10:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.help.org (mail.help.org [70.90.2.18])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 74201147
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 25 Jun 2015 04:10:54 +0000 (UTC)
Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA
	; Thu, 25 Jun 2015 00:10:51 -0400
References: <COL402-EAS109000AAC490BCF2DD69116CDAF0@phx.gbl>
	<558B4632.8080504@bitcoins.info>
	<CALohRkj89mgZTYXQxd0a-mB3SVdMjEF6-9jUm75m=D1wLNZSqg@mail.gmail.com>
From: Milly Bitcoin <milly@bitcoins.info>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <558B7F46.6060106@bitcoins.info>
Date: Thu, 25 Jun 2015 00:10:46 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CALohRkj89mgZTYXQxd0a-mB3SVdMjEF6-9jUm75m=D1wLNZSqg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
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: Thu, 25 Jun 2015 04:10:55 -0000

I am not giving an opinion on the incentive process for developers.  I 
am just saying it exists and it needs to be taken into account when 
developing a process. Pretending it doesn't exist or taking it as some 
kind of personal insult does not do anything to advance the process.  
The developer incentives feeds into the consensus process.

Depending on some kind of "rough consensus" with unstated 
personality-based rules of the game works fine with small projects.  As 
the project gets larger that does not scale as can be seen with the 
recent events.  That is just a taste of what will happen in the future 
as new issue arise.  Developers will end up spending all day tweeting 
and making videos instead of writing code.

The current process does not guarantee changes are approved on technical 
merit alone and that is part of the problem.  Since there is no defined 
process people make claims of all sorts of motives that may or may not 
exist.  The idea is to get a defined process that gives a certain level 
of assurance to outsiders that the process is based on things like 
technical merit.

Russ


On 6/24/2015 11:42 PM, Gareth Williams wrote:
> On Thu, Jun 25, 2015 at 10:07 AM, Milly Bitcoin <milly@bitcoins.info>
> wrote:
> <snip>
>> Also, the incentive for new
>> developers to come in is that they will be paid by companies who want to
>> influence the code and this should be considered
> <snip>
>> Now you are left with a broken, unwritten/unspoken process.
> Your former statement is a great example of why "rough consensus and
> running code" is superior to design by committee.
> An argument should be assessed on its technical merit alone, not on
> the number of people advancing it -- a process that would be open to
> exactly the type of external manipulation you say you are concerned
> about.
>