We agree there should be a way to gauge sentiment around a proposal.
This sentiment would serve as a form of temp check for proposals before onchain voting.
We propose integrating the existing poll function on Discourse as a formalized “Temp Check” process.
Abstract
This proposal suggests integrating Discourse’s poll function as a Temp Check mechanism for gauging initial community sentiment on governance proposals. The goal is to establish a preliminary voting stage prior to advancing proposals to an onchain vote via Tally.
Motivation
A Temp Check is a vital step in the governance process, enabling the community to express early support or concerns about proposals before they reach the onchain voting stage. Without this checkpoint, proposals that lack sufficient backing may still advance, leading to wasted resources and unnecessary onchain votes. This initiative seeks to:
Streamline governance with a simple, intuitive tool.
Reduce governance bottlenecks by allowing community feedback at an early stage.
Avoid unnecessary onchain votes for proposals that lack community support.
Rationale
The choice to use Discourse’s poll feature as the Temp Check mechanism comes from both its simplicity and the community’s preference to avoid integrating additional formal tooling that could hinder governance participation. Discourse already serves as the primary forum for discussions, making it a natural fit for an integrated Temp Check process. By embedding polls directly into proposal threads, this process minimizes the need for additional tools while maintaining transparency.
Specifications
This proposal won’t be submitted to Tally. It would kickstart the experimentation of this process as a poll would be added at the end of this proposal. Delegates would signal suppose or oppose using the poll. For newer proposals, this is what an ideal process would look like:
Process Outline:
Proposal Drafting: Proposals will be posted on the Discourse forum in the Proposals section. They should follow the established proposal template, ensuring that all key details are included.
Temp Check Poll: When this proposal is added as a topic on Discourse, a simple poll will be embedded within the post to serve as the Temp Check. The poll will consist of two options:
Support: Indicating early approval.
Oppose: Indicating early disapproval.
Poll Duration: The poll will remain open for a minimum of seven days to allow ample time for community feedback.
Threshold for Success: For a proposal to proceed to an onchain vote, it must achieve at least >50% support from the Temp Check poll.
OnChain Vote: If the Temp Check poll reaches the required threshold, the proposal can proceed to Tally for an onchain vote.
Poll Setup:
Simple Majority Rule: If at least >50% of participants support the proposal, it moves forward. Otherwise, it will either need modifications or will not advance.
Transparency: Results will be publicly viewable, maintaining transparency in the governance process.
Steps to Implement
If this proposal is approved, the governance working group will be responsible for:
Updating the governance documentation to reflect the new Temp Check process.
Educating the community on how to use the Discourse poll function.
Monitoring the use of temp checks and gathering feedback to refine the process as needed.
My only worry is that polls on Discourse are open to anyone who signs up, and that can be a problem if people vote without really getting the topic. Uninformed voters might end up slowing down or even blocking good proposals from moving forward.
Have you come across any ideas on how to deal with this?
I agree with the general sentiment expressed by @Jaf regarding the value of introducing a Temp Check mechanism to gauge preliminary support. However, I share concerns about potential misuse of such a system if not properly structured. Allowing any user—regardless of their integrity or token holdings—to participate could lead to the creation of artificial sentiment, which might not accurately reflect the broader community’s stance.
Moreover, I question the necessity of implementing this change given our current circumstances. With a proposal passing rate on Tally exceeding 90%, it’s evident that only well-supported proposals make it to the on-chain voting stage. As a smaller DAO, we have the advantage of a tightly-knit community where feedback is already exchanged transparently through regular calls and active forum discussions. These channels provide a solid understanding of community sentiment without the need for an additional formalized process.
Implementing a Temp Check may add a layer of complexity without yielding significant benefits at this stage. Instead, I suggest focusing on enhancing our existing communication channels and ensuring that delegates remain actively engaged in discussions, rather than introducing a process that could potentially slow down governance and add administrative overhead.
That said, if the community feels strongly about integrating this process, I would recommend exploring mechanisms to mitigate potential abuse. For example, incorporating a minimum threshold of token holdings or account age for eligibility to participate in these polls could be one way to preserve the integrity of this Temp Check.
In conclusion, while I see the merits of formalizing community sentiment tracking, I believe that in our current structure, we are not experiencing governance inefficiencies that would necessitate such a change. However, if we choose to move forward, we must do so thoughtfully, with safeguards in place to prevent skewed results and to ensure that Temp Checks add value to our governance process rather than disrupt it.
I’m in favour of a temp check stage although I am against using discourse polls and would encourage you to modify this to be snapshot voting. There’s a lot of tooling built around snapshot which allows notifications (e.g. lighthouse) and summarisation and tracking like x23. It also provides a clear, simple record of votes to look back on and allows token gating to avoid spam. Discourse is great as a forum but in my opinion there are better voting platforms.
This is a great discussion, so thank you for bringing it up.
Just I wanted to express my agreement with the concerns raised by @Jaf and @dzonson.eth. Protecting ourselves from potential bad actors is always essential.
As I’m new here, I still have much to learn about how proposals are being handled. Depending on the agility with which proposals are being implemented, it might be beneficial to consider adding a new “temperature check” stage. I suggest looking into the model used by Arbitrum, which includes an additional step through an off-chain vote on Snapshot. I believe this could be an effective way to gauge community interest before moving forward, especially if the DAO grows exponentially in the number of participants. Here’s the link: How to vote on Arbitrum DAO governance proposals
Would second this, and also suggest looking at aave gov process. Simple and straightforward so people know when/how to escalate proposals is essential.
Here’s a doc I wrote for aave mapping out their process:
Thanks for bringing up this suggestion! We are totally supportive of Temperature Checks in governance. In the particular case of Rari, we have notice a feeling of lack of guidance among proposal authors, who receive feedback, but are unsure of the level of support the proposal has in the current stage, which leads to delayed submission times and prolonged times of uncertainty.
Considering Rari DAO size, we agree Forum polls are a good compromise between effective signalling and simplicity. At this stage, Snapshot voting feels like overcomplicating a governance structure that is still growing. Forum polls are way simpler, and can efficiently express the sentiment of community participants, even during the feedback process, as “Against” voters can change their vote once their feedback has been successfully integrated in the proposal.
We share the concern, however, of other members about the reliability of Forum polls and an inaccurate translation between a 1 Person : 1 Vote system in the Forum poll to a token weighted onchain voting in Tally, as we think token holders should have the priority over Forum participants with regards to making a proposal move forward, e.g., a Forum proposal that only gathers 40% of support in the Forum, but these 40% community members have >50% of the voting power that would make the proposal pass onchain.
For this reason, we would like to suggest a change in the poll setup rules, where the proposal needs to gather a minimum of 25% of support in the Forum poll in order to move forward to an onchain vote. In this way the forum poll serves as a signal of minimum support by the community, encouraging proposals to move onchain, while only filtering out those that have little to no support (<25%) and not the “controversial” votes where majority of voting power might be distributed among a minority of Forum supporters.
I have several questions and concerns that I express to you below: It seems to me that there are loose things like 50% based on all delegates or tokens, it would be good to express that 50% alluding to what it is to be clear. I understand that the Temp Check is a way to measure if this experiment using Discourse is being useful, how long would this temp check mechanism be done? In addition to what Jaf expressed, which seems important to me since whether all people, whether they are delegates or not, can vote, I no longer see that as objective.
I would also like to know what the idea is of using Discourse instead of this forum, for example, since here we can have better control and we know that the people who enter and make a soft vote and then the proposals are presented in the community calls. I like the idea of shortening steps, however it seems to me that we could do it with several of the tools that we already use, if it helps me understand why the idea of using Discourse and how it would benefit us I would appreciate it.
It is also known that in a DAO the issue of voting is a challenge. What communication strategies you think could be useful to involve more community members in this Temporal Verification process, ensuring greater representativeness in the preliminary voting stage?
PS: As an idea, I think it would be good to have a proposal curator board in order to see the DAO and the value. I would definitely like to help with that. They can classify and made a TL;DR: props by temp check, maturity and other
Thanks for the proposal, it’s an interesting idea and. It would be good if proposers had a better idea of what to expect from an on-chain vote. However, we are a small DAO, and it’s very rare that the outcome of an on-chain vote is unexpected, right?
Regarding the complexity and duration of a proposal, I also would not be in favor of an additional Snapshot space. That’s rather something to think about, when having a large voter base, and it’s more difficult to navigate the forum.
My main concern with Discourse would be the sybil resistance, as @Jaf and @dzonson.eth already pointed out, that everybody can create a forum profile and vote. Are there any roles or a similar structure that could prevent non-token-holders or delegates from participating in the polls.
I really appreciate the discussion here and all the concerns/suggestions that have been raised.
Thus far, I see three strong points:
Available tooling already in place
Sybil resistance
1-Person-1-Vote vs Voting power concentration
Available Tooling Already in Place
I talked about this briefly during the last proposal review call. The rationale behind using Discourse (Forum) and not tools like Snapshot is to avoid that additional overhead for voters seeing we have very few of them actively participating atm. Our average onchain voter participation is around 16-18. We don’t want to see that number reduce any further by adding this extra barrier (in this situation).
Sybil Resistance
Because of our current small group, it is easy to tackle this. Discourse gives the option to limit voters in polls to trust levels or any other metric we want. We could use this to filter the people who vote.
I agree with the concerns raised here and would edit the proposal to reflect the 25% suggestion from @Jose_StableLab.
Once again, thanks to everyone for sharing their concerns. If we are okay with my comments, I can update the proposal and we can go ahead and have a test proposal with this poll mechanism embedded.
Thank you for the wonderful proposal, @WinVerse; I agree this does not need to go Tally and can remain a social agreement within the DAO. I would, however like to suggest a few improvements to the process:
The poll should be added after a certain amount of time and discussion has taken place (something like 5 days), allowing the author to incorporate any feedback or material changes that need to be made.
Once the proposal is in its final form, the author should add the poll as a comment or embed it within the proposal. The title of the proposal should be changed to reflect that the Temp Check is now open (e.g. [ [RRC - XX] Add Temp Check [TEMP CHECK LIVE].
The Temp Check should only be considered passed after a certain threshold of voters have voted (e.g 7 votes). Alternatively, we could limit the voting to only RARI delegates to ensure there is sufficient awareness of potential upcoming votes (restrict the voting to a delegate group on discourse).
@addie is already working on creating a delegate group for discourse which would make step 3 more feasible. But I would prefer if there was social consensus on what groups and trust levels should be allowed to vote. And yes in this new system a vote would not be able to proceed to Tally until the threshold of votes in the temp check is met ensuring sufficient visibility on all proposal, and reducing the risk of missing quorum.
Thanks for clarifying @WinVerse. Having a verification mechanism in place at the forum sounds good. We should make sure this is a smooth process to though, so new delegates have an easy onboarding.
While I understand @Jose_StableLab recommendation, to stay with a 25% threshold due to the voting power not being reflected in the forum, it kind of reduces the significance of the temperature checks…
Though, it would be worse, if a useful proposal doesn’t get the chance for an on-chain vote, so I’d go with it.
Support @Sixty suggestions to improve the process, especially having a threshold of discourse voters, or maybe time as well (in case there’s not enough delegate participation).
