You pointed out how hard it is to maintain multiple proposals with different features and code, in the current proposal, would it be really have been that much overhead to include a feature switch, something like “liquidity_baking_enabled=true” and propose one with that, and one without? yes, it would be some dead code until the next update, but I am assuming the effect on performance would have been negligible and it removes the need to maintain multiple codebases, good tradeoff?
1 Like
No worries, same here. Thanks for engaging in good faith.
There is such a thing, but as you’ve said, this is not what is happening.
When we get to actual informed disagreement, I would love including the core teams in them, and seeing how we can manage building multiple proposals to reflect that informed disagreement. It is the kind of stuff that we already started to work on, but it is complicated.
This is wrong and does not follow from what you said. Informed disagreements being merely possible don’t mean we should always invest resources in covering for them.
We have limited resources, investing resources to cover for a possibility that is far from being realized is nothing but a waste, and delays actual important things.
There were TZIPs, threads, and blog posts. This was not developed in stealth in a weird corner of Tezos.
The pragmatic is what is already done: devs (core devs and tool devs) make a best effort to integrate everyone’s interests, to be as open as possible, and then are the ones left to do the actual work of developing the thing.
If someone in good faith is unhappy, or has some questions about the thing, they can exchange with core devs.
What is happening here is not a failure of the process where bakers interested were not accounted for or whatever. It is just a controversy being steered using all the typical tools from polemics and rhetorics. (Us vs them, making it about power, asking 10 questions and discarding all the answers, stating that stuff is symbolic when it is shown to be practically meaningless.)
In the current process, bakers do not spend too much time informing themselves about everything because they trust core devs. They trust core devs because core devs have improved the network and never abused that trust.
So no, the consensus was built, the processed work well. Again, what happened is not a failure of the process. It is just a controversy steered after the actual process, literally after the injection.
This is how it has worked since the beginning. I am not sure why you describe it as utopian.
When someone disagrees with, or is confused about, a thing, they inform themselves first and ask around. This happened a tremendous amount of times in the past, this is the normal course of action.
This is not specific to Tezos, this is common courtesy when you are working with people and they never deceived your trust. You don’t just create a public controversy whenever you dislike something. If you get the habit of doing this, you end up with massive bureaucracies where everyone is too afraid to make a move.
5 Likes
Yes. And I have explained this multiple times, including in the Original Post of this thread.
But, and I will repeat it one more time: this does not matter! There is already an escape hatch in the current proposal, that bakers can use to stop LB whenever they want. It was developed with
2 Likes
In Florence, there was no clear consensus on baking accounts, as seen by the fact that it was developed, injected, and rejected by bakers, so no, I would not say that’s how it worked before, how can you tell you had consensus before the injection, if not by the result of the on-chain process? I am worried that what is advocated for here (in good faith and for good reasons) will result in some kind of ethereum style core-dev “consensus making” hidden underneath on-chain governance to make it look decentralized.
1 Like
Exactly, there was no clear consensus on BA before injection because people took part in the governance process and debates that went on before, and the matter clearly was still a hot topic.
3 Likes
Alright, I understand the nuance now…
1 Like
I vehemently disagree that people who have joined/initiated this debate are simply in it for the polemics and rhetorics. Some of them I know personally and their intergrity and dedication to Tezos and its ecosystem is unquestionable. Let’s not steamroll other opinions just because our position seems so self-evident to ourselves
This sounds a bit dramatic. Sure, this discussion has heated up a bit but you yourself started out as a moderate voice and I believe you were engaged in a civilized manner. I myself am grateful that a core-dev has added his very valuable insight and you actually pushed me over the fence that LB should be tried (yes, I know - that was not the point). You have to be able to take some flak, even when the counterargument to you seems…
My point is mirrored by this quote:
I will now go and vote for both proposals. I will also make sure to be more active in following proposals - that has to be the main takeaway for bakers. I hope the other side will also take away something useful from this discussion, though. It takes both sides to improve.
P.s. Gabriel, your inputs in this discussion were very helpful and I hope you do keep building Tezos. There is absolutely no animosity towards core-devs on my part (and probably most people who “informedly” disagreed). Let’s not make an elephant out of a mouse.
2 Likes
You are correct, this is a very important point, and indeed, I was not clear enough. I too believe that people who participate in the controversy are not “in it for the polemics and rhetorics”. I also believe people have “no animosity towards core-devs”.
Unfortunately, there are other things than intents that matter.
First, people don’t need to be “in it for the polemics and rhetorics” to let debates degrade to polemics and rhetorics. They just need to use those tools. For instance, among other things: making it about power, or constantly asking new questions without actually caring for their actual answers.
Most people in political debates are completely honest, but the landscape of online political debates is still bad and dominated by polemics and rhetorics.
Second, consider the situation where some people among core devs pushed others to become more open, only to be met with a lack of interest from other people, and then an after-injection controversy.
They had already faced, internally, the counterargument that being open does not matter, as people won’t read whatever is put out, won’t participate, and that controversy can still arise.
The current situation proved these counterarguments right, and, unfortunately, of course, breaks the trust in making the process more open. And it does so, regardless of intent of the people involved in the controversy.
I believe this is not definitive: we can always repair trust, make things better. But is not free and takes actual time and effort. The current situation is a big step back.
I will reply to the rest later
[EDIT: here comes the later]
I believe you are sadly wrong here.
Public controversies have a strong effect on people. Most tech people that I have encountered in my life (not only in Tezos) explicitly avoid public stuff for fear of online drama.
I, for one, am personally willing to sometimes talk publicly, and can take some flak. But you should make no mistake that this is indeed a setback. There is no single Mr.CoreDev, there are instead many core devs with various opinions, and it takes time and effort to convince people.
We had conversations where we discussed how open we should be, how valuable it would be, if others were going to participate, how much time and energy we should put in, how to change our processes so that things become more visible, and if people were going to react badly.
Tech people are usually skittish, and proof-by-example is the strongest form of argument. So, you can guess whose arguments are emboldened when this kind of situation arises.
I am voluntarily not quoting the examples of polemics to avoid boosting them, but if you read the other topics, you can easily find them and see what I am referring to. You will see that the way you express your opinions has nothing in common with this. And if you don’t, we can talk about it in private 
Not coincidentally, you can see that the place that is the most polemical content is the place with the most reactions.
Same here. The reason I am replying is because I believe you are in good faith. The same way, I have absolutely no animosity toward you.
Me taking the time to unfold my reasonings is a sign of respect toward the readers. Any abruptness should be understood as me being tired on a Friday and having limited time to dedicate to online posting, rather than to me disliking you or anyone else.
4 Likes
More generally, from a core dev perspective, this completely breaks trust. Our job is already hard enough, and we already have trouble recruiting. If on top of this we have to offer a white glove service to people who don’t take the time to participate to critical discussions, but still feel entitled to create a controversy, we might as well already stop, I can tell you it’s not worth it for anyone with our skillset, at any price point.
I think anyone is entitled to create a controversy, like you here with your post.
From engineer point of view this is bad take, users (holders&bakers in this case), more than usual don’t read documentations, don’t follow procedures and I understand that this cause frustration, believe me as a developer, I know how it feels.
But, I need to remind you that part of devs job (or project manager if any) is to know how to communicate changes, communication (like respect) is a two-way street, is a failures from everyone, there is no point to create a controversy of a controversy to shame the other group, we are all together on this. Also, assuming a failure remind us that we are human, and make us humble, a necessary thing to have good relationship and sane debate.
I’ve the major of respect for core devs, more in these environment, at the same time nobody here is forced to continue so I guess they are doing it because they feel is important, has future and economically makes sense.
So, I’ll recommend to learn from this experience, do a blameless post-mortem, and try to mitigate the same problem in the future.
2 Likes
So far, the procedure has been followed. When there were disagreements or confusions (and there have been!), they were worked out long before injection. As mentioned earlier, it has resulted in periods where there have been multiple well-founded proposals.
And in my experience, bakers and users do read documentation.
Actually, I really do not understand this part. Are you saying we should treat bakers as naïve users? I understand this argument for holders, as XTZ must be as fluid as possible to them. But bakers have various responsibilities, and are expected to be more involved than simple holders or naïve users.
You might not realize, but dev (not only core dev) communication has already improved a lot. Over the last 2 years:
- Tezos Agora was created
- Blog posts + Changelog + Explanations about all protocol upgrades were introduced
- Core devs have participated more and more on Tezos Agora
- TZIP for protocol upgrades were introduced
We already know that we have to communicate around changes, and that protocol upgrades are critical, this is not new information. You don’t need to remind us of anything.
We are investing energy in it (mostly Nomadic, Marigold was just created and we need to onboard the new devs first), but it takes time, and resources.
But even then, as explained, taking time to learn about things and discussions is critical to the governance process, no new process, number of proposals or communication skills will be enough of a substitute. Making multiple proposals is not a substitute for discussion and information: we literally integrated an escape hatch so that bakers can disable LB whenever they feel like it, but people still wanted to make a proposal without LB! Even if we made 2 proposals, there could have been concerns over the lack of proposals with different pairs, rates, etc.
We can not do more than integrating what we expect to be in the bakers interests when no one comes to the public discussions. This is true of all stakers (users, dapp devs, tool builders, etc.), it just so happens that in the current hot topic, bakers are at the forefront.
4 Likes
the procedure has been followed.
Bakers not engaging in discussion in early stage means procedures were not followed.
bakers and users do read documentation.
In that thread is clear many do not.
Are you saying we should treat bakers as naïve users?
No, and I don’t think users are naïve, or if that condition implies something to change how I need to communicate with them, dismissing legit question because of that one guy or group is in a certain condition is a fallacy of thinking.
I do think trying to force other people actions is harder than adapting my own assumptions and actions.
We already know that we have to communicate around changes, and that protocol upgrades are critical, this is not new information. You don’t need to remind us of anything.
Again, this is not the way we can communicate without noise.
I was present here in December reading LB proposal, I didn’t write anything as I wrote in the other thread, and I understand what was wrong then and now, anyone can remind you something in any time, is in you if you take it or not. Like you did mentioning things over the past 2 years that I already knew.
taking time to learn about things and discussions is critical to the governance process,
Agreed, although, I’ve read at that time in both occasions, and for me, was not conclusive, the initial proposal received almost the same push back as backing accounts or similar.
As nobody stake as the user stakeholder or something similar here, maybe the devs couldn’t do a proper follow up. I don’t blame anyone, I’ve read comments not answered from both parties.
We can not do more than integrating what we expect to be in the bakers interests when no one comes to the public discussions
We can always improve, but for that first we need to recognize that we can be wrong.
3 Likes
*I will try to bring some new perspective, from a core developer who created his own team because he was not happy with the past status quo.
Gabriel, thanks for conveying your perspectives in a clear, succinct manner.
Key takeaways for me
- enormous amount of work required when increasing the # of proposal options
- critical requirement for the Tezos community to stay informed and engaged
I will vote to support liquidity baking, because the status quo is not working in terms of adoption.
However, I have serious reservations similar to those stated by other posters. I understand that asset options were limited at the time of proposal and the DeFi is still immature.
tzBTC is a bad option because it is so exclusive. In December 2020, I contacted tzBTC minters (including Bitcoin Suisse, Sygnum) and was denied because they “cannot extend our services to prospects domiciled in the USA”. I want this experiment to have a decent chance of success and not be hampered from the start.
Elsewhere you mentioned that you’re looking for more developers. I’ve held this firm belief, and perhap I’m wrong, that the Tezos network needs more developers to drive progress. What are the obstacles to hiring? To the best of your ability, can you give us a brief overview of the number of developers in the core teams?
1 Like
This is very well said. Thanks for writing this. I agree wholeheartedly.
1 Like
You removed the first part of my sentence which was “So far”.
Bakers had so far respected the procedure. This is the first time this happens. Re-reading my answer with this mind will clear out some other points.
I fundamentally do not care one bit about things like who is wrong, or who recognizes or admits to what. From my point of view, this is only a blame game, and nothing good comes out of them. I am mostly interested in practically improving stuff.
Improving stuff does not require anything like a postmortem, or public apologies. It requires ideas, resources, and then putting in the time to use those resources to build upon those ideas. As explained in the post you replied to, devs had ideas, and durably put resources into them.
Now, the question is, what do others plan to do? Do they plan to actually put in the time and resources to improve things? If so, let’s do this together, I will gladly help!
I have no idea what you are referring to. You said it received a comparable push back to baking accounts: was this in any public place?
For instance, your account first message was from 3 days ago, and you state in this message that you agreed with LB back then when you read about it back in January.
If it was actually not conclusive, why not tell anyone about it? On the dedicated thread on Tezos Agora? Or, if you did not want to clutter it, in private to any core dev?
Thank you Gabriel for creating this thread and sharing your interesting thoughts. I would like to reply to what I think are some of the key arguments you have raised.
As explained by @arthurb, the protocol vote is a ratification step (basically making sure that a proposal is not rogue), more than a “deciding among X competing options” step. The reason is very simple. Maintaining competing proposals is hard!
Even if you consider only 10 small independent one-line changes, you get 2^10 combinations of changes, which is ~1000 different proposals
Many other concerns have been brought up that would make this number blow up even further. This suffices to show that voting (let alone on-chain voting!) is not the right mechanism to build such consensus.
On-chain voting is not the right mechanism for developing the details of a proposal (e.g. which pairs to support, by how much to increase the block reward, at what point to set the sunset clause, etc.) but it is absolutely the right way to create consensus around the idea. Compare it to the Brexit referendum, which suffered from a critical flaw in the voting process. Voters were presented the option of no Brexit or Brexit. However, “Brexit” doesn’t exist. Should the UK stay in the customs union with the EU or revert to WTO trade rules? Should it remain under the jurisdiction of the European Court of Justice or not? Should it continue to apply EU competition rules? Should there be customs checks on the border between Ireland and Northern Ireland or in the Irish sea?
There are a thousand “Brexits”, and it should have been defined beforehand what Brexit would look like, so voters could have made an informed decision. No one is suggesting that a tree of proposals is included to cover all possible forms of liquidity baking. You are certainly right that on-chain voting is not the right process for that. However, when, through whatever process, consensus is formed around the right way to implement a certain proposal such as liquidity baking, it absolutely makes sense to present that proposal to bakers, and allow them to vote against it. Same as a referendum, if designed well, is a good way to gauge the views of all constituents.
To me you are essentially advocating for off-chain governance, with bakers rubber stamping dev proposals. You said it yourself - few people contributed to the discussion on liquidity baking. How then can you claim to have created consensus? It’s a ludicrous notion, to be honest, and I don’t think you should be trying to impose consensus through the discussion process as a way to incentivise people to engage more in those very discussions. Stakeholder participation is what it is - much as you might like to see otherwise, if formal amendment proposals create more attention and discussion than anything else, then clearly it should be treated as more than just a ratification step.
Fundamentally, this ask for one proposal with and without LB is just people coming at the end of the entire process and asking to make a late and uninformed choice
I could not disagree more. At the end of the day, the proposal is what really counts as it will update the protocol. This will always receive more attention than the underlying discussions and it is crucial that in this very step all bakers have the ability to express their preferences simply, clearly, in a well-informed manner and competitively. This implies that for changes that are not strict technical upgrades, an option representing the status quo is injected alongside, with clear argumentation for why the particular change in question would be beneficial to Tezos. You seem to be distrustful of bakers - I would not be. I would trust them radically and give them real decision power - that is how you encourage bakers to be informed and to participate in discussions.
Including liquidity baking alongside non-technical changes forces bakers’ hands to an extent, it makes it impossible for bakers to express a very plausible viewpoint: being in favour of incorporating code optimisations, but against liquidity baking. It is like backdoor American politics: present a huge bill with your pet projects inside, and hope it passes the Senate floor because of all the bipartisan things included as well. This is a bad precedent for Tezos governance. Liquidity baking should have been presented on its own merits. (Note that I am in favour of liquidity baking, and don’t mean to write it off as a pet project. I am just comparing the process.)
There is already an escape hatch in the current proposal, that bakers can use to stop LB whenever they want
This is disingenuous, because while it is true, to my understanding this would among other things require the participation of exchanges to reach the threshold, which would be a radical departure from their role in governance so far. The escape hatch would be triggered only in case this proposal turned out to be an abject failure, and I don’t think this is the standard that should be set for proposals. The governance process is there for a reason - it lets bakers express their preferences in a consistent, accessible, and transparent manner. (I am more in favour of the sunset clause howver, I think this was a very good part of the proposal).
2 Likes
I fundamentally do not care one bit about things like who is wrong, or who recognizes or admits to what
From my point of view, this is only a blame game, and nothing good comes out of them
I agree on that, I’ve never suggested either.
Improving stuff does not require anything like a postmortem, or public apologies.
I’ve never said anything about public/private apologies.
Blameless post-mortem are useful tools to improve procedures/processes and operative protocols, I won’t argue about wide spread successful practices, but I respect your opinion.
I have no idea what you are referring to. You said it received a comparable push back to baking accounts: was this in any public place?
Liquidity Baking (ex liquidity mining) was introduced as a generalisation/rethinking of Liquidity mining and Virtual Baker, links
https://forum.tezosagora.org/t/liquidity-mining-on-tezos/2529/4
In the last one (January) you can still see concerns about tzBTC, like:
“I think this is very useful, but could still be improved by using some decentralized version of wrapped BTC with trustless bridges rather than tzbtc.”
For instance, your account first message was from 3 days ago, and you state in this message that you agreed with LB back then when you read about it back in January.
Yes? that is correct, I agreed with the idea from the initial virtual baker to the last version of it, no without reserves and constraints shared with several participants.
If it was actually not conclusive, why not tell anyone about it? On the dedicated thread on Tezos Agora? Or, if you did not want to clutter it, in private to any core dev?
Look, if I agreed with the idea, why I should be on charge to tell everybody that the topic is still not conclusive (or question to the author(s) are pending) and we need to get out of the way a lot of concerns?
Your comment try to imply something about how I behave, this is not relevant to this topic or the other.
Now, the question is, what do others plan to do? Do they plan to actually put in the time and resources to improve things? If so, let’s do this together, I will gladly help!
I did put time to read information, not only from here, but from other channels, I guess we all can learn from this failure, time will tell.
Actually I think it’s absurd and quite disrespectful to compare bakers, who expend considerable effort and commit significant amounts of money securing the Tezos blockchain, voting on concrete proposals with real-life consequences that directly affect their financial interests, to random Twitter users voting on a random Twitter poll with zero stakes and zero consequences.
1 Like
I guess. I still think the proposal would have had warmer reception if a plan was presented to switch to a better asset at some concrete point in the future, rather than just “this turns off in 6 months”.
Regarding the phrasing, I think questions or concerns need not end with a question mark to be worth addressing. Of course the authors are free to respond or not, I think it was an easy opportunity to address some of the concerns early on and outline the plan.
Thank you all for your replies. I now see more where you are coming from 
I am currently writing a new thread that addresses various points made in those replies. After reading them, I believe the most productive thing to do is to actually explain and discuss in greater details some points about governance, talk to all of you soon, and thanks again
4 Likes
I agree with most of what has been said and have learned alot.
At first LB raised my hackles a bit because of names being a part of the proposal (I’m a decentralized purist ).
I kept quite and read.
Now I see LB as an attempt to get what we desperately need right now. I’m glad someone has the ability to provide this.
And it may well work.
Quite right
And good work
1 Like
