Declarations for vote manager, ballot, vote creation (Governance)

[Chris-Hibbert]

What is the Problem Being Solved?

Design (first draft) vote manager, ballot, support for creating a vote with multiple positions

simple APIs with enough clarity that work can proceed on Governance

Description of the Design

TBD

[Chris-Hibbert]

It appears that the natural breakdown is into ballotCounter and registrar. ballotCounter issues ballots and counts them, but don't know who can vote. Examples include binary, IRV and STV. Registrars hand out and collect ballots, but don't have to understand what question is being asked. Examples here include committees (equal weight, known membership) and shareVoting.

ballotCounter intrinsically assumes that ballots (or equivalently, voters) have weights. Committee votes just have equal weights, but not different logic. Different ballotCounters should be able to share logic for enforcing quorum and requiring super-majority.

In order to allow the possibility of open nominations, building the ballot is a separate operation.

Ballots {
createBinaryBallot(name1,name2)
createIRVBallotBuilder()
createSTVBallotBuilder()
}

The BallotBuilders have addPosition(). The builders might be held closely, or attenuated and shared.

The voteManager that creates the ballot, ballotCounter and registrar has responsibility for scheduling, closing, invoking the count, and publishing or carrying out the result. Each of those can be pluggable, though first implementations may take short-cuts there. For legibility purposes, all of the parameters should be accessible from the ballot (or its invitation), particular any that direct automatic execution.

[Chris-Hibbert]

The design has settled into a Registrar (empowers an electorate by handing out VoterInvitations) and BallotCounters. These are orthogonal and stay out of each other's business.

A Registrar might create the electorate by the act of issuing invitations, or might issue invitations to parties that can prove membership in a class. The Registrar will manage Questions to be presented to its voters, but doesn't know how the questions are created, collected, or counted. When the counting is done, the Registrar can reveal the outcome.

BallotCounters manage Ballots for particular questions. When created, choices are made about how many options there are and how the voters' preferences are aggregated. Some of these choices are pluggable (counting quorum), and others are specific to the approach (Binary, Instant Runoff, Single Transferrable Vote, Approval voting, etc.) Voters who have an invitation for a particular question can get a BallotTemplate from the BallotCounter and submit it to their VoterFacet.

A single Registrar might have several Questions of different forms, and the voters will have to interpret the ballots to see how to make a selection.

We get legibility for who can vote on which questions by having invitations show the BallotCounter and Registrar instance they were issued by.

When a contract wants to make it visible that an electorate controls the contract's parameters, we'll want to make the connections between contract, Registrar, and BallotCounter visible. We'll have ElectionManagers for that, which will identify their electorate and BallotCounter. The contract can then designate the ElectionManager, to make the electorate and process of creating Questions for the ballot legible.

[Chris-Hibbert]

This PR has served its purpose as a point of coordination.