Quorum is designed to ensure that there is a broad representation of the community voting their opinion for a given proposal. @solarcurve handles much of the governance work and obviously puts forth a ton of effort to keep things moving. As the person posting the votes, he also is often the first person to vote on each one. He currently has more that enough voting power to put every proposal over quorum, making the quorum effectively useless.
Proposal
Increase the quorum sufficiently high that this is not the case. Open to discussion. Double it?
Disclaimer
All opinions my own.
PS
Fwiw I generally trust @solarcurve, I just think the quorum is useless in the current state of things so it should be updated
it looks like the majority of proposals that had less voting interest still finished around 350k to 500k. with Solar’s added voting power i think these would have finished above 500k, so that seems like a good number to me.
Yeah, it makes sense, and around 500k is a good start since Solar has around 250k voting power. This would make his power around 50% of the quorum, which is still a lot but an improvement on the current state.
Voting power and participation have increased over the past few months, which is also a good sign.
Side note: The “% quorum reached” on snapshot is a great addition.
I think we could go to 1M veBAL but 500k is a step in the right direction. Since this is already a governance focused proposal, it might also make sense to enshrine the 30 day waiting period for re-voting. Perhaps with an exception in case a proposal has undergone significant changes, since for example if the OpCo funding proposal fails it would be very bad for the ecosystem to have to wait 30 days for a revised proposal to go to a vote.
I believe we would have to classify “significant changes” otherwise it is very subjective. Maybe another exception type would apply to elements critical to the protocol being able to continue, such as infrastructure support.
Not sure if this applies, but it would be nice if more voters were required to post their reasoning like the delegates do (voters with x% of voting power for instance). If they dont give their reasoning againt a proposal then it is subject for re-vote in a shorter timeframe. Otherwise I dont see the difference between 5 days and 30 days, as a proposer you are guessing what people didnt like in a number of situations.
I think 500k is fine for now, let’s re-evaluate for 1m later.
Yeh “significant changes” is a bit iffy to define.
If the proposer outlines the key changes in bullet points between the original and new proposal then the community can decide if its fine to bypass the 30 day waiting period. A quick forum poll (not ideal) can signify if the community is happy with the proposed changes.
On the topic of governance changes, I have a couple of ideas to add too.
Add abstain as an option
Some delegates can’t vote abstain, so they have to avoid voting in certain votes. This addition is more of a formality to add abstain to all votes esp in recording voting history. It also helps if some voters aren’t sure in voting yes or no, maybe they didn’t have enough time to read a proposal and be fully informed in their decision.
Also, if Balancer ever considers using Karma then an off-chain vote has some form of weighting in creating a reputation.
Integrate the Karma discourse plugin
Karma just released a plugin for people to use within discourse forums too.
Total votes delegated to them (One signal to indicate their incentives in the DAO)
Their snapshot and on-chain voting stats (Shows how active are they really in governance)
Their Karma reputation score
Currently, we don’t use Karma, so only the first 2 points apply to us. Getting this integrated would be great for people to have a better understanding of the contributors and their voting power, without manually checking on another website.
I think we can add abstain as an option if that’s helpful. I’d love to do the plugin too but we’re on a managed hosting of discourse. If I read the installation instructions correctly this would require migrating to a self-hosted instance. Which is also maybe possible but would have to be looked into.
I personally don’t see any benefit in adding an “abstain” option just to pump up the quorum. Who benefits from this? In the absolute extreme case:
1 vote yes
0 votes no
1M votes abstain
The result here is that the people who are “not voting” by abstaining give more authority to the minority who are. If you didn’t have time to read the proposal, just don’t vote.
It’s not to benefit the quroum. It’s more to allow those who have to abstain (those associated with the foundation) because if we use plugins like Karma then this shows their voting history more accurately.
Also not everyone might not be informed enough to make a decision, so an abstain option provides another route.
I also don’t think using an extreme case is valid since that won’t happen.
I second this. @solarcurve usually adds an abstain option to votes where foundation members (or others) have to abstain. I don’t mind having it for certain votes only.
Founder of Karma here! Thanks @Bobbay_StableLab for recommending our plugin.
It can work with managed hosting instances too. ENS uses a hosting provider and we were able to work with them and install it easily. I can’t message you here, feel free to message me on Telegram, same user id.
Could you elaborate more on this, or share a link to the discussion? Adding abstain in order to “make a record” only and contributing to quorum feels weird to me.
