{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-24\n📝 Original message:I'm sorry but this is absolutely not the case, Milly. The reason that\npeople get defensive is that we have a carefully constructed process that\ndoes work (thank you very much!) and is well documented. We talk about it\nquite often in fact as it is a defining characteristic of how bitcoin is\ndeveloped which differs in some ways from how other open source software is\ndeveloped -- although it remains the same in most other ways.\n\nChanges to the non-consensus sections of Bitcoin Core tend to get merged\nwhen there are a few reviews, tests, and ACKs from recognized developers,\nthere are no outstanding objections, and the maintainer doing the merge\nmakes a subjective judgement that the code is ready.\n\nConsensus-changes, on the other hand, get merged into Bitcoin Core only\nafter the above criteria are met AND an extremely long discussion period\nthat has given all the relevant stakeholders a chance to comment, and no\nsignificant objections remain. Consensus-code changes are unanimous. They\nmust be.\n\nThe sort of process that exists in standards bodies for example, with\nworking groups and formal voting procedures, has no place where changes\ndefine the nature and validity of other people's money. Who has the right\nto reach into your pocket and define how you can or cannot spend your\ncoins? The premise of bitcoin is that no one has that right, yet that is\nvery much what we do when consensus code changes are made. That is why when\nwe make a change to the rules governing the nature of bitcoin, we must make\nsure that everyone is made aware of the change and consents to it.\n\nEveryone. Does this work? Does this scale? So far, it does. Uncontroversial\nchanges, such as BIP 66, are deployed without issue. Every indication is\nthat BIP 66 will complete deployment in the very near future, and we intend\nto repeat this process for more interesting changes such as BIP65:\nCHECKLOCKTIMEVERIFY.\n\nThis isn't about no one stepping forward to be the \"decider.\" This is about\nno one having the right to decide these things on the behalf of others. If\na contentious change is proposed and not accepted by the process of\nconsensus, that is because the process is doing its job at rejecting\ncontroversial changes. It has nothing to do with personality, and\neverything to do with the nature of bitcoin itself.\n\n\nOn Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin \u003cmilly at bitcoins.info\u003e wrote:\n\n\u003e I have seen this question asked many times.  Most developers become\n\u003e defensive and they usually give a very vague 1-sentence answer when this\n\u003e question is asked.  It seems to be it is based on personalities rather than\n\u003e any kind of definable process.  To have that discussion the personalities\n\u003e must be separated out and answers like \"such-and-such wouldn't do that\"\n\u003e don't really do much to advance the discussion.  Also, the incentive for\n\u003e new developers to come in is that they will be paid by companies who want\n\u003e to influence the code and this should be considered (some developers take\n\u003e this statement as an insult when it is just a statement of the incentive\n\u003e process).\n\u003e\n\u003e The other problem you are having is the lead developer does not want to be\n\u003e a \"decider\" when, in fact, he is a very significant decider.  While the\n\u003e users have the ultimate choice in a practical sense the chief developer is\n\u003e the \"decider.\"  Now people don't want to get him upset so nobody wants to\n\u003e push the issue or fully define the process.  Now you are left with a\n\u003e broken, unwritten/unspoken process.  While this type of thing may work with\n\u003e a small group of developers businesses/investors looking in from the\n\u003e outside will see this as a risk.\n\u003e\n\u003e Until you get passed all the personality-based arguments you are going to\n\u003e have a tough time defining a real process.\n\u003e\n\u003e Russ\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On 6/24/2015 7:41 PM, Raystonn wrote:\n\u003e\n\u003e\u003e I would like to start a civil discussion on an undefined, or at least\n\u003e\u003e unwritten, portion of the BIP process.  Who should get to vote on approval\n\u003e\u003e to commit a BIP implementation into Bitcoin Core?  Is a simple majority of\n\u003e\u003e these voters sufficient for approval?  If not, then what is?\n\u003e\u003e\n\u003e\u003e Raystonn\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/5488f38b/attachment-0001.html\u003e"}