rich1.0npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzwhttps://nostr.ae/npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzwnjumphttps://nostr.ae📅 Original date posted:2015-06-24 📝 Original message:+1 Mark! On Wed, Jun 24, 2015 at 9:50 PM, Mark Friedenbach <mark at friedenbach.org> wrote: > I'm sorry but this is absolutely not the case, Milly. The reason that > people get defensive is that we have a carefully constructed process that > does work (thank you very much!) and is well documented. We talk about it > quite often in fact as it is a defining characteristic of how bitcoin is > developed which differs in some ways from how other open source software is > developed -- although it remains the same in most other ways. > > Changes to the non-consensus sections of Bitcoin Core tend to get merged > when there are a few reviews, tests, and ACKs from recognized developers, > there are no outstanding objections, and the maintainer doing the merge > makes a subjective judgement that the code is ready. > > Consensus-changes, on the other hand, get merged into Bitcoin Core only > after the above criteria are met AND an extremely long discussion period > that has given all the relevant stakeholders a chance to comment, and no > significant objections remain. Consensus-code changes are unanimous. They > must be. > > The sort of process that exists in standards bodies for example, with > working groups and formal voting procedures, has no place where changes > define the nature and validity of other people's money. Who has the right > to reach into your pocket and define how you can or cannot spend your > coins? The premise of bitcoin is that no one has that right, yet that is > very much what we do when consensus code changes are made. That is why when > we make a change to the rules governing the nature of bitcoin, we must make > sure that everyone is made aware of the change and consents to it. > > Everyone. Does this work? Does this scale? So far, it does. > Uncontroversial changes, such as BIP 66, are deployed without issue. Every > indication is that BIP 66 will complete deployment in the very near future, > and we intend to repeat this process for more interesting changes such as > BIP65: CHECKLOCKTIMEVERIFY. > > This isn't about no one stepping forward to be the "decider." This is > about no one having the right to decide these things on the behalf of > others. If a contentious change is proposed and not accepted by the process > of consensus, that is because the process is doing its job at rejecting > controversial changes. It has nothing to do with personality, and > everything to do with the nature of bitcoin itself. > > > On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin <milly at bitcoins.info> > wrote: > >> I have seen this question asked many times. Most developers become >> defensive and they usually give a very vague 1-sentence answer when this >> question is asked. It seems to be it is based on personalities rather than >> any kind of definable process. To have that discussion the personalities >> must be separated out and answers like "such-and-such wouldn't do that" >> don't really do much to advance the discussion. 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 (some developers take >> this statement as an insult when it is just a statement of the incentive >> process). >> >> The other problem you are having is the lead developer does not want to >> be a "decider" when, in fact, he is a very significant decider. While the >> users have the ultimate choice in a practical sense the chief developer is >> the "decider." Now people don't want to get him upset so nobody wants to >> push the issue or fully define the process. Now you are left with a >> broken, unwritten/unspoken process. While this type of thing may work with >> a small group of developers businesses/investors looking in from the >> outside will see this as a risk. >> >> Until you get passed all the personality-based arguments you are going to >> have a tough time defining a real process. >> >> Russ >> >> >> >> >> >> >> On 6/24/2015 7:41 PM, Raystonn wrote: >> >>> I would like to start a civil discussion on an undefined, or at least >>> unwritten, portion of the BIP process. Who should get to vote on approval >>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of >>> these voters sufficient for approval? If not, then what is? >>> >>> Raystonn >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/3c10f6ac/attachment.html>