From: Mike Hearn <mike@plan99•net>
To: "Wladimir J. van der Laan" <laanwj@gmail•com>
Cc: g@amethyst•visucore.com,
Bitcoin Dev <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 18:05:58 +0200 [thread overview]
Message-ID: <CANEZrP016FjDZx9cNMbPR5nV0BRVxBCf-GEfD+59JseJcNWjvA@mail.gmail.com> (raw)
In-Reply-To: <20150618154640.GA7840@amethyst.visucore.com>
[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]
>
> So then: make a proposal for a better process, post it to this list.
>
Alright. Here is a first cut of my proposal. It can be inserted into an
amended BIP 1 after "What belongs in a successful BIP?". Let me know what
you think.
The following section applies to BIPs that affect the block chain consensus
rules or the peer to peer protocol and thus require changes to Bitcoin
Core.
Once a draft BIP has been submitted to bitcoin-development for
consideration, the Bitcoin Core maintainer will deliver a preliminary
yes/no verdict within three weeks. This verdict may be informed by the
debate that has taken part in the previous three weeks. If more time is
required, the maintainer is required to request an extension from the BIP
author, who may then elect to force an immediate decision (risking a no),
or choosing to allow more time.
The verdict will meet the following criteria:
- It will address the latest version of the BIP at the time the verdict
is rendered.
- In case of a rejection, it will spell out and describe the technical
rationale for this decision. Opinions held by other people are not
considered technical rationales: if the maintainer agrees with a technical
point made during discussion, he must own that opinion for himself.
Therefore no BIP will be rejected on grounds of controversy, disagreement,
lack of consensus or otherwise.
- In case of rejection, the maintainer will provide a clear, specific
list of actionable steps the BIP author can take next. For example, a list
of what changes would address the technical objections raised. In case the
maintainer believes no change could ever make the BIP acceptable, the list
must consist of instructions for how to create a patch set and, in the case
of changes to the consensus rules, how to initiate a hard fork.
A BIP, even once rejected, may live on in the BIPS repository, though its
entry in the index may be sorted below others. The BIP author may update
the BIP with a summary of any resulting discussion. As such a summary may
be inherently contentious in case of a dispute, the authors wording of that
summary is final and may not be subject to meta-debate.
[-- Attachment #2: Type: text/html, Size: 2646 bytes --]
next prev parent reply other threads:[~2015-06-18 16:06 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
2015-06-18 15:46 ` Wladimir J. van der Laan
2015-06-18 16:05 ` Mike Hearn [this message]
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=CANEZrP016FjDZx9cNMbPR5nV0BRVxBCf-GEfD+59JseJcNWjvA@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=g@amethyst$(echo .)visucore.com \
--cc=laanwj@gmail$(echo .)com \
/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