I apologize for the length of this. If you just want a TL;DR, please see the final two paragraphs.
Honestly I’m of two minds on the subject. I think both options are reasonable and justifiably valid ways to move forward in this specific instance. That said, there are a number of things about option B that make me uncomfortable. Meanwhile, the only reason I can think of against option A is my impatience for the new features I feel are (or were) on the verge of being activated on the chain.
Let’s all remember that we’re discussing a patch to Babylon 2.0.0. The 2.0.0 implies that there was a 1.0.0. Indeed, just a few weeks ago there was seemingly unanimous support for Babylon 1.0.0. Then they decided to add more to it and submitted Babylon 2.0.0 during the proposal phase. Did these bugs exist in Babylon 1.0.0? Based on the information I can find, I think it seems likely that they did. Nevertheless, there was a fair amount of confusion in the community about what exactly changed between Babylon 1.0.0 and 2.0.0. Nomadic Labs updated their blog post, but didn’t detail the changes. They just said the instructions in the post (on how to verify the hash and vote for the proposal) were updated. IMO, things should have been more clearly communicated.
In other words, this amendment period has been handled somewhat poorly from the start. We’ve gone from 1.0.0 to 2.0.0 to 2.0.1 in a single amendment period. And with just a few days left in the testing phase before we’re supposed to vote for or against it, how can we be sure that even this patched code doesn’t have other hidden bugs that haven’t been discovered? Rapid/Agile development has its place, but I don’t believe that the Tezos protocol is the right place for it.
Perhaps it would be prudent to go with option A and vote nay during the promotion phase in order to drive home the message even further to Cryptium and Nomadic, as well as anyone else who may submit proposals in the future, to slow down and make sure that the proposed changes are thoroughly vetted and clearly explained/documented before proposing them.
It seems as though patching the proposal in the middle of the amendment process can set a nasty precedent and send the message that there’s no need to worry about code quality since it can always be patched later if something comes up.
Yes, emergency patches have been done in the past, and will likely be done again in the future. These are perfectly valid and desirable ways to improve the protocol. However, this is not an emergency. This is the testing phase doing what it was designed to do: test to make sure the new code works as intended and doesn’t break anything. The result was that we found out that the new code does not work as intended, and it does break things.
This event has brought up many wonderful ideas of how the amendment process itself can be amended in the future so that a similar situation doesn’t delay progress on the chain as much as this one will if we go with option A. That’s all well and good, and I am in favor of some of the changes that have been suggested in that regard.
But as things are now, with the amendment process designed the way it is currently designed, it seems the most correct thing to do is to vote nay for code that doesn’t pass muster during the testing phase.
In two or three years, a three month delay now will be long forgotten. On the other hand, I think it’s plausible that going for option B could irreparably damage some people’s trust in the amendment process as well as damage the reputation of Tezos for many years to come. If people feel the rules have been subverted, it could drive people away from Tezos and onto a Tezos fork (such as Dune). I can’t help but see some parallels to Ethereum’s “The DAO” hack and its resulting schism. Option B could result in there being a Tezos and a “Tezos Classic” in the very near future.
In short: I am not aware of any argument which sounds reasonable to me in which option A can be considered “illegal” (i.e., subverting Tezos governance), immoral, or unethical. But I do think that some people would reasonably find option B to be “illegal,” immoral, or unethical, even if I personally find it to be justifiable in this specific instance.
For these reasons, and probably many others I won’t mention because this is long enough already, I am inclined to err on the side of caution and support option A over option B, and vote nay
during the promotion phase. While I fully respect and feel I understand those who choose to support option B, I think it would do us all well to temper our impatience for the much desired features upcoming in Babylon. Let’s make sure that Babylon works correctly and that it gets passed through the amendment process in a way that does right by all citizens of this commonwealth.