From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5bLn-0000AF-8t for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 15:03:31 +0000 X-ACL-Warn: Received: from mail-ig0-f171.google.com ([209.85.213.171]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5bLl-00084P-QW for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 15:03:31 +0000 Received: by igbzc4 with SMTP id zc4so129260297igb.0 for ; Thu, 18 Jun 2015 08:03: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:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=dNnqVWfZpMsQ3Eair3fmAmZwk0mTHZMKwdF6Lc/Ztxk=; b=KYtqX1nkq69zleAUBgJTjE9UeZV53gDDycnw3B6lKRmCsx0Z7KMHfxZ6T/K2bdG3me VaL9qxsFGPcpgxd30gQ4r5ec7rV4q+iZdj6GVjg/hRAttIJpiwJR045DZ2gpMWEPnhML tE++TCJJ3ymhz9Ssi0c1ZTb3+Hd/nJCt5qh3bw9NuDpD088RreREkKfgZacUnq9ogRep 9xCXGlfH46M2jxKc/rkySnpHkDli1Oyw9ioTkI65887JIs8U1s+DSsjLebjNsdCf98XY N+WP8kpYBaSexbZkIpDIlJA+DXA2EpD7Zo6BbgQHz3RZIQgY2qXyk6p6qlWP6jwL/TZO RnjA== X-Gm-Message-State: ALoCoQn6o2cHy81WO73W7pQS2LnPTCZRJfi8ElFvL2odk0Wv/MsobcJKrLIU1+yrEH9NkVWU8AIh X-Received: by 10.50.142.9 with SMTP id rs9mr18388740igb.17.1434639802222; Thu, 18 Jun 2015 08:03:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.149.20 with HTTP; Thu, 18 Jun 2015 08:03:01 -0700 (PDT) X-Originating-IP: [50.0.37.37] In-Reply-To: References: <55828737.6000007@riseup.net> <20150618111407.GA6690@amethyst.visucore.com> From: Mark Friedenbach Date: Thu, 18 Jun 2015 08:03:01 -0700 Message-ID: To: Mike Hearn , Bitcoin Development Content-Type: multipart/alternative; boundary=001a11c2ff1ccaeb380518cc1bc2 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Z5bLl-00084P-QW 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 15:03:31 -0000 --001a11c2ff1ccaeb380518cc1bc2 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn 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. --001a11c2ff1ccaeb380518cc1bc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn <mike@plan99.ne= t> wrote:
The first issue is how = are decisions made in Bitcoin Core? I struggle to explain this to others be= cause 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, wh= o are these people? Is it "whoever reverts the change last"?=C2= =A0 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 Unit= ed States Supreme Court Justice Potter Stewart to describe his threshold te= st for obscenity which is relevant here: "I know it when I see it.&quo= t;

It is hard certainly, and perhaps even impossible to w= rite down a system of rules that is used to resolve every dispute among cor= e developers. But that doesn't mean it isn't obvious to all the par= ticipants what is going on. If a contentious change is proposed, and if aft= er sufficient debate there are still members of the technical community wit= h reasoned, comprehensible objections who are not merely being obstinate in= the views -- a neutral observer would agree that their concerns have not b= een met -- then there is a lack of consensus.

If there wa= s 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 ga= med. 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.
--001a11c2ff1ccaeb380518cc1bc2--