You are worrying too much for 3 lost months of development. If the amendment process takes 3 months, then we have 4 updates per year. I don’t even think Bitcoin Forks update at that pace.
Edit: I will probably vote at the end of the voting process, if there’s a lot more weight on B, I guess I will go with the crowd on this one. I’m more concerned for the protocol reputation than anything, I rather A but willing to accept B, I believe in the general intelligence of the crowd.
I think @adrian makes a good point.
I didn’t realize this at first, so was thinking Option A, but now that I realize that whatever we choose, it will be chosen by the governance process. So for this reason I’m going to go with B, and due to other points taken about each little bug. We need to be practical. I’m sure in the next protocol or the one following there will be an elegant solution to this problem. That is one thing that everyone agrees on so far. If it’s something that everyone unanimously wants, I don’t feel so bad about “faking” it for this vote, the practicality has won me over for this one.
I’m seeing many users here who almost seem apologetic that they are not bakers and thus cannot vote. However, I find it important that also delegators join this discussion and given that there are many more delegators than delegates, they should ideally even outweigh the latter group. Although bakers are those who will finally vote, it is the delegators’ voices they represent! Therefore, no need to apologise.
The answer is B. We shouldn’t pretend we are old pros at this game yet. The birthright of tezos is the consensus mechanism. We can use it right now to make the chain better when it makes complete logical sense.
No need to hold to a ultra conservative late game strategy right out of the gate. The chain is robust (or in this case, antifragile) enough that a hiccup like this is a great chance to harvest the lessons learned, make the quick agile fix, look forward to the change, and move on. There’s nothing out of the spirit of tezos by doing so, in fact, I would say it’s the opposite.
What’s rad is how much a small two line bug has already taught us. Lots of good ideas getting bubbled up, and the safety nets caught it. Tezos is going to be so strong if we keep learning and improving like this.
Choose B!
I agree with a majority of what ZHZ has said, but I am still on the fence whether to go with B or not. On the one hand, from a strict constructionist point of view as ZHZ has described, Proposal B clearly goes against a strict constructionist interpretation. We all came into this community supporting tezos with the understanding that the governance rules is what bind us. The rules were also designed in such a way that IF we decided we wanted to change any of it, there’s a process prescribed to do so, which shows the ability to be flexible. From a strict constructionist point of view, if you don’t follow the rules set in place already, what assurances can you give to others that in the future you will adhere by the rules set in place and that something like this won’t be used for more contentious proposals or possible nefarious reasons? By not sticking to a strict constructionist perspective, it adds an aura of illegitimacy to the whole process or a “taint” to the process and erodes trust in the governance/trust in the blockchain. No matter how big or trivial the changes might be, the rules in place are there for a reason, and if we want to change the rules then we need to do so through the proper mechanisms. The closest example I can think of is why so many foreign investors trust doing business in the USA. They know that by entering into a contract in the USA and that contract meets all the legal requirements of a valid contract, they can have that contract enforced if a party breaks any terms of that contract. It gives them the confidence to do business in the USA knowing that the rules of the game won’t be changed while the game is being played; i.e.; ex post facto law and contract clause (see Art 1 §10 clause 1 of USA constitution)
We have the mechanisms to change the governance structure, so why don’t we do that instead of slowly eroding the process that’s in place so that there’s no hint of any scienter? I do see people posting about not wanting to waste time another 3 months in the process and that’s also a valid consideration. I understand that this may seem like a long period, (which I personally think it is), but it’s the price we pay for having legitimacy. [if we want to shorten it, then this is exactly the process to do so.] I would hedge on showing more restraint from exercising possible shortcuts until the governing process is formally changed. Do we honestly feel like this delay will throw off Tezos’ trajectory or overall goals? I haven’t seen any compelling arguments that such a delay would do so. In proverbial language, the foundation of this house was born from blood, sweat, tears, and fire, so why not protect the house at all cost?
I also see arguments of what if a major security flaw is shown and we have to hotfix it, wouldn’t that be overriding the governance process? Yes, it would override the governance process, but those sort of fixes are seen as keeping the integrity of the whole system that if it’s not done, the whole structure will crumble. Back to the house example, if the house is on fire/security flaw is noticed, you wouldn’t need to pass a governance proposal to call the fire department to put out the fire/hot fix/patch the flaw. You straight up call the fire department and tell them to come now instead of waiting for a vote to be done. Would stakeholders be upset that such a fix was done? Probably not since if it wasn’t done, then the whole infrastructure/foundation would collapse. Is that the case here? I don’t think it is and for that reason I am leaning towards option A rather than B.
Ultimately, whatever the community decides, keep in mind that the world is watching and that we are setting a precedent with on-chain governance which to my knowledge has not been done yet and I am grateful that we are engaging in these type of discussions. This is on-chain governance at work with a healthy engagement of discourse to ensure democracy happens.
There seem to be two different views on Babylon 2.0.1. A) A strict conservative take where Babylon must be rejected and resubmitted since it contains a small bug. B) A more pragmatic stance where Babylon can be accepted, and the bug fixed outside the governance process.
Tezos has a formal governance mechanism and we vote on actual code. In fact, it is Babylon 2.0.0 we will be voting on and that will introduce a bug. To prevent the bug from ever reaching the protocol a hotfix has already been released.
Approving a proposal with a known bug and forcing a situation where we need to apply a hotfix is not an ideal situation. It is however something that can easily be coordinated today, but it will become much harder and riskier with increased maturity and level of decentralization. Delaying an upgrade of the protocol 3 months because of a small bug is not a good solution either. Babylon will make smart contract development and delegations much easier. It’s of strategic importance to give smart contract developers the tools they need and to make it as easy as possible for exchanges and multi-currency wallets to support delegation.
The governance mechanism isn’t perfect and needs to be tweaked to better handle situations like this. Many ideas on how this can be done have already been presented. I want to propose that we are pragmatic today, because we can. And become more conservative over time, because we must. Therefore, I am in support of alternative B (Yay) in the promotion vote.
We as part of the Tezos community voted for “yay” in the current promotion phase of Babylon. Our thoughts are as follows:
Most community members committed on a set of features for an upgrade proposal that they’ve read up on from articles provided by Nomadic Labs and Cryptium Labs
What is the intended purpose of the “testing period”?
2.a The protocol proposal with the intended and described functionality should be tested.
2.b As many people as possible and capable should investigate in order to find bugs.
2.c The goal of a proposing developer team is to succeed with its proposal.
2.d If the honest search for a bug is disincentivized due to unproportional punishment e.g. a three months wait time because of a logging error (opinion) the team could hope for it to be not found in order to hotfix it after the upgrade.
2.e As Arthur said in his medium article - hard forks will always be there for bug fixes.
If a hotfix is needed then it must be confirmed with a quorum which also means that a high number of bakers is updating the client ensuring the transition.
A discussion and media campaign is needed to inform everyone. But actually, everyone should look at the monthly updates of the Tezos client anyway.
You should have a read here: https://medium.com/tezos/there-is-no-need-for-hard-forks-86b68165e67d
You should read the top highlight of his article.
We wish to avoid hard-forks because, as a mechanism for introducing innovative but contentious changes, they tend to be centralizing. We do not do it out of some weird intrinsic rejection of hard-forks . We value pragmatism.
Although, he also mentions this:
If buggy or malicious protocol upgrade passes through the various defenses of the governance procedure, not letting it permanently cripple the network is a perfectly valid reason to hard fork.
The bug did not pass through the last defense of the governance procedure, which is the promotion period, we still can reject it but people here are too impatient, I still think there is no rush.
The question here becomes how do we in an on-chain governance fashion modify the on-chain governance mechanism to allow for midstream patching when bugs are found during the test vote period without violating the rules in the meantime and as we discuss how to move forward on Babylon 2.0.1?
The sticky issue here is that many would take issue with new code being applied to an existing proposal that was not there before. I am not sure how serious of a concern this maybe. I imagine developers, bakers, and teams within the ecosystem will somehow test the patched Babylon 2.0.1 containing the fixes within the promotional period itself before casting a vote. If new bugs are found or any other issues I will advocate to vote against the passage of Babylon 2.0.1 and recommend that Babylon 2.0.1 be reintroduced and that additional proposals be attached that would allow for the patching of code if and when bugs are found during the test vote period midstream as @Bitcom suggested a few days ago.
I am completely behind both Cryptium and Nomadic and have absolute confidence in their abilities to safely achieve what they have proposed with option B. However, I will instruct bakers who I provide assistance and ongoing consultation to not vote until the very near the end of the promotional vote period. This allows us to think longer about the situation and leaves us plenty of wiggle room for voting against Babylon 2.0.1 if the community is made aware of any new or old issues found in the patched code.
Reputation is also affected by A. For example, we have several companies and other devs specifically waiting on Babylon to either release their apps/features or things they need to move forward with development.
In line with what others have mentioned, I’m inclined to support option B, but will ultimately support whatever the community decides.
I do not feel it would harm the image of on-chain governance, as it’s still being decided via the governance process. On the other hand, I actually feel option A does more (short-term) damage to the image of on-chain governance, that we are forced to delay by 3 months over a tiny bug when there are developers and companies waiting on Babylon changes to release their apps or new features. In addition to what Gabriel said above, we are also working with other companies that are waiting on Babylon. And like Adrian said, this incident could repeat with future proposals as well.
Tezos is still a young protocol, and we have time to improve the governance process so that this doesn’t happen in the future, so I disagree that this would somehow prove that on-chain governance is flawed if we patch it. Either way, I agree with improving the process and allowing proposals to be amended during the testing phase or other such improvements already mentioned here.
Happy voting 
I agree wholly with @adrian’s analysis of the technical preferability of the possible outcomes. My position is that because of:
That 1-4 constitute grounds for the ‘democratic hard fork’ (my suggested terminology) to be able to be trivially subsumed by an only marginally more expansive definition of the Tezos social contract than the ‘on-chain self-amending literalist’ view.
XTZ Antipodes therefore supports option B for reasons of expediency and ecosystem momentum, and will vote accordingly nearer the end of the period, barring further problems revealed in testing. Parenthetically, I also support exploration of changes to the amendment and testing processes to reduce the incidence of future events like this.
References:
On the Social Contract of Tezos
Based on what has been discussed here and also other information and materials available we will vote yay next week.
We prefer the pragmatic approach. This is software development and there will be a need for fixes. The governance process is to have a consensual agreement on how the chain will evolve.
Adding an extra 3 months just for the sack of “governance integrity” is something we firmly oppose. We need to keep the momentum and integrate further improvements within the chain and keep creating the incentives to encourage developers and companies to come to Tezos.
There was a statement coming from Banque de France that blockchain needs to have privacy features. We believe that currently Tezos is the best available proof-of-stake network. Once we have privacy features integrated within the protocol, we will have the best smart-contract platform.
For the next protocol amendment, we need to amend the governance process to better handle this sort of situation. We need a clear path to patch an upgrade during the voting process. A patch should be allowed as long as the substance of the upgrade is not changed or as ZHZ puts it: the fix does not materially change the meaning or intent or function of the original proposal .
We will vote yay by the end of this week.
we have the governance, and with consensus the hot fix will go ahead, that is all.
I am leaning to voting no. I get that it will delay things by 3m but my primary point is this, if we think the promotion testing etc needs to change then we should inject a proposal to change it. Using the argument that oh it’s just a small change sets a precedent that i feel is more dangerous than, “we will never allow another protocol upgrade, because we will always find a bug”
Tezos needs to last and grow for many many years, 3m is nothing. These are my early thoughts I have not finally made up my mind. but I am leaning towards NO.
For those that keep describing our current situation as a dangerous precedent, I would like to ask you to read more on the material published prior to the fundraise. The goal of Tezos governance is to make good decisions – hard forks are a fully legitimate and expected approach for the types of important (yet easy to fix without altering the intent or structure of the code) bugs found in Babylon.
People are free to disagree with the pragmatic over dogmatic intention of our governance, but please do so with full knowledge that choosing to be dogmatic runs counter to how our governance was originally intended.
Here are two relevant quotes from articles about the design and intent of the Tezos governance:
“However, there will almost certainly be hard-forks in the life of Tezos . Allow me to explain. There are circumstances in which changes to the ledger through the governance model aren’t practical and do not present any advantage over a simple hard-fork. In those scenarios, the desired change is typically uncontroversial and widely desired among the participants.”
and
"Principles
Principles are the moral code that governs the Tezos network. They represent the core beliefs, the foundational concepts, upon which Tezos is built.
Non-dogmatism
We value hard rules and will follow them to their natural conclusion, but not to their absurd conclusion. We believe in being consistent, but not foolishly consistent."
Here are just some of the relevant articles and video:
Good point.
