From: Milly Bitcoin <milly@bitcoins•info>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Date: Thu, 18 Jun 2015 11:30:06 -0400 [thread overview]
Message-ID: <5582E3FE.7010206@bitcoins.info> (raw)
In-Reply-To: <CAOG=w-sWimZTJe=4gCvC5R7SAEK+Nvo-hZtM7xC-bBQd0pG3mw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2727 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4319 bytes --]
next prev parent reply other threads:[~2015-06-18 15:30 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 8:54 odinn
2015-06-18 10:00 ` Mike Hearn
2015-06-18 11:14 ` Wladimir J. van der Laan
2015-06-18 11:47 ` Wladimir J. van der Laan
2015-06-18 13:36 ` Mike Hearn
2015-06-18 15:58 ` Gregory Maxwell
2015-06-18 12:29 ` Pieter Wuille
2015-06-18 12:50 ` Wladimir J. van der Laan
2015-06-18 12:56 ` Benjamin
2015-06-18 13:49 ` Mike Hearn
2015-06-18 14:05 ` Wladimir J. van der Laan
2015-06-18 14:16 ` Mike Hearn
2015-06-18 14:53 ` Milly Bitcoin
2015-06-18 14:56 ` Jeff Garzik
2015-06-18 15:13 ` Milly Bitcoin
2015-06-18 14:53 ` Jeff Garzik
2015-06-18 16:07 ` justusranvier
2015-06-18 16:28 ` Jeff Garzik
2015-06-18 17:04 ` justusranvier
2015-06-18 17:42 ` Alex Morcos
2015-06-18 18:01 ` Milly Bitcoin
2015-06-18 18:23 ` Gavin Andresen
2015-06-18 18:44 ` Alex Morcos
2015-06-18 18:49 ` Jorge Timón
2015-06-18 19:31 ` Ross Nicoll
2015-06-18 21:42 ` Matt Whitlock
2015-06-18 21:49 ` Mark Friedenbach
2015-06-18 21:58 ` Jeff Garzik
2015-06-18 22:33 ` Mark Friedenbach
2015-06-18 22:52 ` Jeff Garzik
2015-06-18 23:25 ` odinn
2015-06-18 23:16 ` Ross Nicoll
2015-06-19 0:57 ` Chris Pacia
2015-06-19 5:59 ` Eric Lombrozo
2015-06-19 9:37 ` Mike Hearn
2015-06-19 9:53 ` Benjamin
2015-06-19 10:08 ` GC
2015-06-19 10:19 ` Mike Hearn
2015-06-19 10:52 ` Eric Lombrozo
2015-06-19 11:31 ` Jorge Timón
2015-06-19 12:26 ` GC
2015-06-19 11:48 ` Brooks Boyd
2015-06-21 14:45 ` Owen Gunden
2015-06-18 21:55 ` Ross Nicoll
2015-06-18 19:24 ` Matt Corallo
2015-06-18 19:32 ` Gregory Maxwell
2015-06-18 12:38 ` Milly Bitcoin
2015-06-18 13:31 ` Mike Hearn
2015-06-18 13:50 ` Pieter Wuille
2015-06-18 15:03 ` Mark Friedenbach
2015-06-18 15:30 ` Milly Bitcoin [this message]
2015-06-18 15:46 ` Wladimir J. van der Laan
2015-06-18 16:05 ` Mike Hearn
2015-06-18 16:20 ` Wladimir J. van der Laan
2015-06-18 22:49 ` odinn
2015-06-18 16:11 ` Milly Bitcoin
2015-06-18 11:41 ` Lawrence Nahum
2015-06-18 14:33 ` Bryan Bishop
2015-06-18 18:09 ` Melvin Carvalho
2015-06-18 22:10 ` odinn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5582E3FE.7010206@bitcoins.info \
--to=milly@bitcoins$(echo .)info \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox