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

API data required: proposal vote weighting data #2998

Closed
edd opened this issue Feb 19, 2021 · 2 comments · Fixed by #3408
Closed

API data required: proposal vote weighting data #2998

edd opened this issue Feb 19, 2021 · 2 comments · Fixed by #3408
Assignees
Labels

Comments

@edd
Copy link
Member

edd commented Feb 19, 2021

Somewhat similar to #2828, we don't currently get enough information in the API to display coherent information about the success or failure of an auction.

What we have now

{
  proposals {
    party { id }
    id
    datetime
    state
    yesVotes { value }
    noVotes { value }
    rejectionReason
  }
}
{
  "data": {
    "proposals": [
      {
        "party": {
          "id": "48f597747766cb9b000134d318973b09e75916aa27e9803d0e1a7604827a5565"
        },
        "id": "64a526d02f2dc201f0521a865bc94ae982036f586324e39914f6f99a33768c46",
        "datetime": "2021-02-18T18:55:46.468366843Z",
        "state": "Enacted",
        "yesVotes": [
          {
            "value": "YES"
          },
          {
            "value": "YES"
          },
          {
            "value": "YES"
          }
        ],
        "noVotes": [
          {
            "value": "NO"
          }
        ],
        "rejectionReason": null
      }
]}}

So we can infer that this one passed because there's more yes votes than no votes. But after #2997 when the calculation is fixed, there may be more YES votes than NO votes but it might be rejected.

What we need

Extra fields on each vote

By adding two extra fields on the VOTE, we can see what effect each vote has on the proposal. The downside is this would need to be updated with each transfer, so the half-arsed solution is to split this in to two types: OpenVote and AcceptedVote, and only track these fields on AcceptedVote after the proposal voting period closes.

Current VOTE object

type Vote {
  value: VoteValue!
  party: Party!
  datetime: String!
  proposalId: ID!
}

Proposed VOTE object

type Vote {
  value: VoteValue!
  party: Party!
  datetime: String!
  proposalId: ID!
  governanceTokenBalance: String!
  governanceTokenWeight: String!
}

Extra fields on each proposal

This replaces #2828, as having a simple tally would not give us sufficient detail

Current PROPOSAL object

type Proposal {
  id: ID
  reference: String!
  party: Party!
  state: ProposalState!
  datetime: String!
  terms: ProposalTerms!
  yesVotes: [Vote]
  noVotes: [Vote]
  rejectionReason: ProposalRejectionReason
}

Proposed PROPOSAL object

type Proposal {
  id: ID
  // Extra field because it will be useful in future - for open proposals, the current governance asset. Closed: asset at closing time
  governanceAsset: Asset!
  reference: String!
  party: Party!
  state: ProposalState!
  datetime: String!
  terms: ProposalTerms!
  // All vote and tally related data moved in here
  voteData: VoteData
  rejectionReason: ProposalRejectionReason
}

type VoteData {
  yes: VoteDataSide
  no: VoteDataSide
}

type VoteDataSide {
  votes: [Vote]
  count: Number!
  totalGovernanceTokenWeight: Number!
}
@campbellssource
Copy link
Contributor

We currently have a Fairground activity around voting scheduled which will give this issue a Lot of attention. So...

Bump.

@ValentinTrinque ValentinTrinque self-assigned this Apr 22, 2021
@ValentinTrinque
Copy link
Contributor

Working on it.

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

Successfully merging a pull request may close this issue.

4 participants