Intro
This task discusses improvements to Cagendas, including technical and design considerations, voting implementation, and viewing past votes in Snapshot. The goal is to enhance the functionality of Snapshot for ongoing polls and enable better tracking to see past votes in Snapshot, which would allow us to have topic polls continue throughout the season. The document suggests allowing topic proposals and votes to carry over from week to week, implementing a system to see votes at a certain time, and exploring the use of Snapshot API or The Graph for more detailed voting data. Technical implementation details and examples are provided for reference.
Table of Contents
- Intro
- Rationale
- To Do
- Technical Implementation
- Figure out how to See Votes at a Certain Time in Snapshot
- Introduction
- More Detailed Rationale
- Current Status
- How can you see past 'blocks' in snapshot? For example, how can you see the Snapshot votes at a certain time ?
- Technical Implementation
- How to See Past Votes in Snapshot:
- Example of Using Snapshot GraphQL API:
- Example via The Graph Subgraph:
- Further Documentation:
Rationale
To Do
- create the proposal as described below
- do we need to make polls each week
- can people change their votes
- would it be helpful to make a subspace for this?
- is ranked choice voting best for this or one of the other options (like for example weighted choice voting)?
- would each topic be an answer in one poll or a poll in itself?
- I think that each topic would likely be a poll in itself, because otherwise it seems like it would be difficult to add options to an existing poll and we’ll likely want to post many options which may exceed the limit of options per poll
- would people need to split their votes across multiple proposals or do they exhaust when they are used? Does it matter?
- I think either way would probably work fine at this point and be a big improvement over the status quo, so i shouldn’t overthink this
- if you have just one ranked choice does snapshot make it e voting order at the time that
- should each topic also have a vote at the end?
- perhaps i should do this to set an example and a standard…
- Yes I should aim to do this and consider the best way to do it
- When the question involves a binary or multiple choice answer then it’s easy to create a poll and ask people to vote in it. I should create simple polls that work in this way and go along with the topic at hand whenever possible, and I should think about the best polls to ask for each topic
- I also need to consider the best workflow for more open-ended questions. For example, what if I ask an open-ended question like “What are the best metrics to measure impact to the collective” or “How should the Collective measure and reward the impact of educators?”
- Ranked choice voting and weighted voting is also a very helpful type of voting that I should use often when designing these topic proposals. Ranked choice and weighted voting can be simpler than open-ended questions because they don’t require people to actively participate, but they provide much more granularity and detail than a binary or multiple choice poll
- I think there are some great ways to do open-ended questions, and ultimately these are some of the best formats of questions that I should ask. It’s really about turning the open-ended question into a ranked choice question (or a weighted voting question).
- We can play games like Speeches or RetroPitches where each person gets 2 minutes to answer the question, then the group rank orders the best (six) answers. They would be voting for the people in this case (unless we had automatic transcription and could quickly add their text answer to the poll).
- Another way that it could work is by asking people to submit answers in text, either during or before the event. The short answers in text are then added to the poll options and participants vote on the polls.
- Another way it could work is to go into small random breakout groups then choose an answer via consensus or elect a delegate to represent the group in the community room.
- These kinds of open ended questions that are translated into ranked choice voting provides a fun way to engage participants, a structured chance to speak and hear others, and a lot of helpful data for the Optimism Collective
- We should also experiment with weighted voting and quadratic voting in the future, but for now i think that ranked choice voting is generally the best because it provides a lot of helpful data while making the process as simple and fun as possible, while also working in alignment with the ranked choice voting in the Respect Game
- Keep in mind that there’s no need to just make one poll per event. I could make a survey of say 5 polls that we seek to answer throughout the event and the polls could help guide the conversation, making it both more fun, engaging, and valuable for data scientists or badgeholders who want more quality opinions
- This is also similar to how we asked several questions in RetroPitches. Again, we should also remember to make it fun and award participants while accomplishing the goal.
- Awards:
- Consider awarding Respect to the top 6 participants
- I think that this shouldn’t be required and anyone can make a proposal without a poll, but generally it will be more fun, interesting, and valuable when there is a poll included as part of the topic or discussion where people can vote with Respect
- This gives a good conclusion and reason to the discussion. It specifies what we are aiming to achieve and provides an outcome with data that the Optimism Collective can use to make more informed decisions based upon a credibly neutral, inclusive, and democratic system of Respect
- It also gives more meaning and power to Respect. It demonstrates the utility of Respect and makes it more likely that people in Optimism will accept it more as a ‘currency’ of influence and reputation, especially when we include it in our promotions that show how the Respected community members voted and allow other people in the Optimism collective to also vote
Technical Implementation
- I think that the voting would reset each week for topics, but I’m not sure how this would work technically.
- Would people need to re-propose the same topics each week if they didn’t get discussed?
- Would people need to vote on topics each week?
- What happens if a topic has been partially discussed but people want to discuss it more
- I think it probably makes the most sense to allow topic proposals and votes to carry over from week to week, but allow people to change their votes whenever they want
- This way we minimize the amount of extra work needed, but allow people to flexibly change their preference for the topics as they see fit
- Some people will likely vote for topics and then forget about it even after a topic has been discussed, but overall that is ok because:
- the topics and votes will reset at the end of each season
- the people who forget will likely have less respect or voting power
Figure out how to See Votes at a Certain Time in Snapshot
Introduction
- It would be good to implement a system of where people can vote on topics, priorities or other kinds of polls and be able to see the amount of votes for the different polls and options at a set time without needing to set a poll to end at that time
- This would allow us to have ongoing polls in subspaces where we can vote on topics, priorities or other kinds of polls throughout the season without needing to end the poll at a certain time and recreate the same poll again later
Table of Contents
- Intro
- Rationale
- To Do
- Technical Implementation
- Figure out how to See Votes at a Certain Time in Snapshot
- Introduction
- More Detailed Rationale
- Current Status
- How can you see past 'blocks' in snapshot? For example, how can you see the Snapshot votes at a certain time ?
- Technical Implementation
- How to See Past Votes in Snapshot:
- Example of Using Snapshot GraphQL API:
- Example via The Graph Subgraph:
- Further Documentation:
More Detailed Rationale
Current Status
- It seems possible to see exactly how many votes a poll or option received at a certain time using the Snapshot API or The Graph. For example, we could see the amount of votes for all polls and options at 17 UTC on Monday.
- However, this appears to require some programming and does not seem possible to do without additional technical work.
- So for the beginning of Season 3 we should play a form of Cagendas where topic creators need to create a topic each week.
- This is a less ideal solution than allowing topics to be proposed once a season without needing to re-propose them each week, but it is simpler to implement technically.
- With this setup, as host @Dan Singjoy will make sure to prepare some topic proposals each week in advance by Friday so that we have interesting topics to vote on
- Of course everyone else is welcome and encouraged to make topic proposals as well. Feel free to propose whatever topics interest you!
- We should work towards developing the solution with the API or The Graph to make it possible to keep topics up throughout the season
- The section below shows the current limitations of viewing votes at a certain time on Snapshot and how a
How can you see past 'blocks' in snapshot? For example, how can you see the Snapshot votes at a certain time ?
In Snapshot, each proposal captures a "snapshot" of the voting power at a specific block number when the proposal is created. This block number represents a point in time on the blockchain, and the voting power of each participant is determined based on their token holdings at that time. If you want to see the votes at a certain time, you would need to look at the proposals that were active or created around that time and examine the snapshot block number associated with those proposals.
Snapshot does not directly offer historical browsing by block number or timestamp in a user-friendly way through their web interface. However, you can view past proposals and their details, including the snapshot block number, by navigating through the proposals list in each space on Snapshot.
To view detailed historical voting data, you might need to access the underlying blockchain data directly or use blockchain explorers that can query specific block numbers to see the state of token holdings at that time. This approach requires technical knowledge about blockchain data queries and might involve using tools or APIs that interact with the Ethereum blockchain (or other supported blockchains), where the token snapshots are recorded.
For more detailed guidance on creating proposals and understanding the snapshot mechanism in Snapshot, you can refer to their official documentation: Snapshot Docs.
Technical Implementation
In Snapshot, you can see the state of votes at a particular point in time using "snapshots," which refer to the blockchain state at a specific block number. Here's how you can view past votes:
How to See Past Votes in Snapshot:
- Access the Snapshot Proposal URL: Every proposal on Snapshot has a unique URL. Visit the specific proposal's URL to access details of that vote.
- Check Snapshot Block Numbers:
- Each proposal displays a "snapshot" block number. This indicates the block at which the votes were counted.
- The snapshot block number ensures that votes are calculated based on user token balances or other criteria at that specific block number.
- Inspect Voting Details at the Snapshot Block:
- Within the proposal page, you can see the list of voters and their voting power at the snapshot block.
- The proposal page will list how each address voted and the weight of their vote.
- Use GraphQL or Snapshot API:
- Snapshot provides an API that allows you to query past proposals and voting results directly.
- Alternatively, you can use The Graph's subgraphs to query historical data using GraphQL.
Example of Using Snapshot GraphQL API:
To find past votes via the API, you can use a query like this:
graphqlCopy code
{
proposal(id: "your-proposal-id") {
id
title
choices
scores
votes {
voter
choice
vp
}
snapshot
}
}
Replace "your-proposal-id" with the actual proposal ID you are interested in. This query will return:
- The proposal ID and title.
- Choices and their respective scores.
- Detailed voting data including voters, choices, and their voting power.
Example via The Graph Subgraph:
You can also query historical Snapshot votes using subgraphs:
graphqlCopy code
{
proposals(first: 10, where: {space: "space-id"}) {
id
title
choices
scores
votes {
voter
choice
vp
}
snapshot
}
}
Replace "space-id" with the specific space ID to get the proposals and votes in that subspace.
Further Documentation:
- Snapshot GraphQL API
- The Graph Subgraphs
These tools should help you explore historical Snapshot votes at specific times effectively.