Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5cPq-0005Wa-Br for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 16:11:46 +0000 Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1Z5cPn-0006Gu-0N for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 16:11:46 +0000 Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA ; Thu, 18 Jun 2015 12:11:35 -0400 Message-ID: <5582EDAC.2070609@bitcoins.info> Date: Thu, 18 Jun 2015 12:11:24 -0400 From: Milly Bitcoin 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> <20150618111407.GA6690@amethyst.visucore.com> <5582E3FE.7010206@bitcoins.info> <20150618154640.GA7840@amethyst.visucore.com> In-Reply-To: <20150618154640.GA7840@amethyst.visucore.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) 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 0.1 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5cPn-0006Gu-0N 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 16:11:46 -0000 You misunderstand what I am saying. I am not saying I have a specific process that should be followed, I am saying that whatever the process is then it should be formalized or at least written down. That way the stakeholders have something to work with and keeps people on track. Since some people are saying they don't really know what the process is the first step would be to describe the current process. I don't fully understand the current process but I can see it is not formalized and nobody can even give me a clear description of what it is. Once you have it written down then changes/improvements can be proposed. The first baby step was already done by the Foundation in developing that risk study. A NIST guide for developing such a document is at http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf. No one person can come up with this and it would take buy in from several different people who have expertise in specific technical areas as well as experts in coming up with test plans. I recently suggested to the people running the MIT lab that they look into developing a program along those lines. Gavin also recently suggested that list of Bitcoin metrics be developed to help resolve the current disputes. I can help develop this process if there is interest. Russ On 6/18/2015 11:46 AM, Wladimir J. van der Laan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > >> 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. > So then: make a proposal for a better process, post it to this list. > > In practice there has been zero interest in improving the BIP process. > > E.g. the BIP process was adapted from the Python Enhancement Proposals by Amir Taaki (in 2009 or so?). It hasn't really changed since then, apart from some spelling and grammar corrections. It is not specifically adapted to Bitcoin, and doesn't make a distinction between for example, consensus changes and non-consensus changes. > > So that's up to someone to do. You seem to be enthousiastic about it, so go ahead. > > Wladimir > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBCgAGBQJVgufFAAoJEHSBCwEjRsmmAmYIAI9ndrMoqEuoaP5t+7W42UuH > sh5qR7hojCCoZZl1N+rQ63UXcPBO/V4NUkUG97S3qpEFDzuoYSbOX2Eh+TRfK+s+ > U+BpLhWteSexJ3N9aiFuR0q5jgesAzLZ9wtq1gCPI/Zu5/fgYBP4AVTiQGdXCZtv > m6ZDKCf+aB/fW/59/AiY44NkMDjVQieEVRiT1IPFJULWesOOdtv7UoqIpz0vDa/5 > Jplm41j8IpTPioJKSwUi5qzSDrF7O39PC9LMXNRx/0FIuYfwqJpvF0Frc+vtPpjQ > llKE7945uMXz3FLSV0Orx26XPal/MuF5AYOPNk6pJfwYw7q91AUvQxVFepBa9vw= > =dMO9 > -----END PGP SIGNATURE----- >