Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional data requirements for democracy proposal and referenda #118

Open
ishrak-imam opened this issue Jul 22, 2022 · 6 comments
Open
Assignees

Comments

@ishrak-imam
Copy link

Bases on what is currently displayed in the app following are some of the extra data requirements.

Referenda:

  • Referenda index (we have the index as part of id, but explicitly expose the index as a separate value)
  • Number of participants voted aye
  • Number of participants voted nay
  • End period (time remaining until voting is open)
  • Activate period (time remaining until activation)
@markdavison
Copy link
Contributor

Not sure what the use of the count of accounts that vote aye or nay. An account can split vote between aye and nay (goodness knows why)... but I think it means that fundamentally the number of accounts does not matter... it is about the staked value.

I see no issues with the other points. Will need to do some investigation to figure out how to get the dates .

@ishrak-imam
Copy link
Author

Not sure what the use of the count of accounts that vote aye or nay. An account can split vote between aye and nay (goodness knows why)... but I think it means that fundamentally the number of accounts does not matter... it is about the staked value.

Your reasoning is justified from the point of one account being able to split vote. But at the same time "x amount of staked vote value is coming from either 10 or 1000 participants" this particular information could be important to the next voter.

I see no issues with the other points. Will need to do some investigation to figure out how to get the dates .

For end period and activate period, these are blockNumbers. So to figure out relative date (from now) form block number we will need the current block and that we can process in the custom resolvers of the litentry graph. Just returning the block number might also be ok.

@markdavison
Copy link
Contributor

Your reasoning is justified from the point of one account being able to split vote. But at the same time "x amount of staked vote value is coming from either 10 or 1000 participants" this particular information could be important to the next voter.

But I think the reason for showing vote based on staked value is that there is no way of knowing how many people are voting. I could have 10 accounts and vote with each one. Its easy to do... but I wonder how useful it is.

How should a split vote be represented?

How should someone who votes one way and then changes their mind? (Only their last vote counts... so presumably it should represent their last vote).

@silva-fj
Copy link

silva-fj commented Jul 25, 2022

But I think the reason for showing vote based on staked value is that there is no way of knowing how many people are voting. I could have 10 accounts and vote with each one. Its easy to do... but I wonder how useful it is.

Well, I think we are talking about two different things here, the staked value is used to determine if the proposal will be approved or not, but it does not represent participation.. Having both, staked value and participation (unique accounts that have voted) are important in different ways for us.

How should a split vote be represented?

I would say it should be represented as it is, same value for both

How should someone who votes one way and then changes their mind? (Only their last vote counts... so presumably it should represent their last vote).

That's correct, the last vote should be the one that counts. This is not an issue that needs to be resolved in the indexer, it should be resolved in the graph.. Eventually we will have some limitations when querying data from the indexer and we will have to do similar to what web3go does, talk with the database directly.

@markdavison
Copy link
Contributor

Well, I think we are talking about two different things here, the staked value is used to determine if the proposal will be approved or not, but it does not represent participation.. Having both, staked value and participation (unique accounts that have voted) are important in different ways for us.

But I don't think the number of accounts necessarily represents participation - one person could have 100 accounts or 100 people could vote with one account. I think fundamentally the design of referenda voting ignores the number of accounts for this very reason.

I would say it should be represented as it is, same value for both

If they vote 10% aye and 90% nay we should add 1 to aye and nay?

@silva-fj
Copy link

But I don't think the number of accounts necessarily represents participation - one person could have 100 accounts or 100 people could vote with one account. I think fundamentally the design of referenda voting ignores the number of accounts for this very reason.

Don't think about people, think about accounts and votes.. If it was one person with multiple accounts, it does not matter to us. We just care how many accounts have voted (only for this particular bit of data we show in the app). We also show the staked value which matters the most.

I would say it should be represented as it is, same value for both

If they vote 10% aye and 90% nay we should add 1 to aye and nay?

Yep

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants