Governance system UX flows

[dckc]

In our July 11 meeting, @leithaus suggested I draw some flow diagrams to clarify some of the options we were discussing.

Let's start with the Dust approach, as it's most clear about how it addresses the issues critical for use in a coop annual meeting.

Dust (#29)

editable source

This addresses the one-member-one-vote issue (#31) by counting only votes from registered addresses. A Jun 3 board resolution requires all members to provide a REV address to the coop in order to vote in the annual meeting.

Tallying the votes (#35) involves non-trivial software development to pore over the contents of the chain and extract the relevant transfers. Regarding the secret ballot stretch goal (#18) this approach allows the coop to discover how each member voted and puts all votes on the public record so that should anyone ever discover which address a member registered, they can look up the member's vote.

This approach addresses the zulip store-of-reference issue (#24) by leaving it out of the picture.

With regard to questions and answers (#34), it's reasonably clear how the board would decide the agenda and the secretary would assign a unique target address to each option on each question. While it's clear how a member's vote is represented on chain, the UX for getting it there is a little less clear. It's possible for a member to manually do a transfer to each target, but that seems arduous. The diagram here suggests an html/js app deployed via IPFS or the like (some content addressable store where the content can't be changed once a URL is announced) that lets the members use normal web forms with radio buttons and one "submit vote" button.

So the role (#33) of the board and secretary are clear. The governance committee could perhaps help the members give feedback on the UX.

Write questions in Zulip; Vote using FE (#28), Dappy (#30)

editable source

I gather each voter generates their own key pair as part of a dappy app. How we ensure (at most) one vote per member (#31) is not clear to me.

My understanding of this approach is that it involves development of a govbot that allows the membership to collaborate on questions; for an AGM, the board would approve the final agenda of questions and answers (#33, #34). The govbot would compute links that include enough information for a dappy app to present the ballot form with questions and candidate answers (#34). Members would take responsibility to see that their votes, in encrypted form, make it to (the right place on) the blockchain.

The strength of this approach is that anyone can, in theory, tally the votes (#35). And votes remain anonymous (#18). The board and secretary take responsibility for the tally, so I suppose they should be provided with some software to do it along with some assurance that the software is correct. Arguing the correctness of C/C++ software is extremely challenging, in my experience.

Write questions in Zulip; Vote in Zulip

editable source

This flow leaves many questions un-answered, as yet:

• one member one vote: REV address, connected with zulip account? #31 how do we ensure one-member-one-vote?
  • #39 is one suggestion: integrate metamask as a zulip authentication mechanism and log using an ETH address correlated to a member's REV address.
• yes / no abstain questions - board, secretary, members #34 how does the board / secretary choose the questions? how do members answer them?
  • some work on a bot is in progress
• The rchain mirror of zulip (#24) is critical path. The design is reasonably clear but engineering a reliable service takes some work.

[jimscarver]

this is the simple case I see using zulip and dappy voter registration of a zulip username

I do not see how functional encryption could be employed here.