Enhancements to Slack emoji-vote process

[gigxz]

Note: this issue has been closed and the remaining items moved to separate tickets: https://github.com/metagov/gateway/issues/181 https://github.com/metagov/gateway/issues/183 https://github.com/metagov/gateway/issues/184

Tracking feature requests to the slack.emoji-vote process:

• [x] For boolean votes, only allow one vote per person. Automatically remove their previous emoji-reaction when a user submits a second vote.
• [x] If channel and users are provided, start the vote in a public channel but only allow the specified uses ("eligible voters") to vote. When ineligible users attempt to cast votes, remove their emoji-react and show an ephemeral message explaining why. https://github.com/metagov/metagov-prototype/issues/122
• [x] Add option disallowed_participants: str[] for list of voters that are not allowed to vote. The disallowed voters have their emoji-reactions removed. (Used by PK to exclude "proposer")
• [x] Add option allowed_participants: str[] for list of voters that are allowed to vote. This could be performed as a group message or in a channel.
• [ ] Add support for single-select choice votes, using the same mechanism of auto-deleting previous votes. Maybe: use options poll_type: boolean|choice and min: int and max: int to specify the min and max vote casts permitted for choice votes.
• [ ] If the voting post is deleted, mark the process completed (maybe with an error). Provide a way to "close" or "cancel" the poll, and a way to grant that power to particular user(s)?
• [ ] Add option private: bool for performing private vote as direct messages to each participant.
• [ ] Add option(s) to allow the caller to customize the behavior of close. Currently it edits the existing message to display the final vote count next to each option. Screenshot of current behavior:

[shaunagm]

What about an optional vote threshold? Basically something that would turn a 51/49 result into a wash - you could set the threshold to 60% and then you'd have to get 60/40 or 40/60 or more to actually produce a result.

Also: do we want to expand options to more than an up or down vote? For instance, allowing an abstain option, or alternatives of the caller's choice?

Part of the complexity here is that you can use emojis to represent a variety of different processes - majority vote (and within that, supermajority vote), consensus process, polls. I don't think we necessarily want to shove everything into one GovernanceProcess, but it would be good to experiment and see what elements can be abstracted out, because I think we do want people to have the flexibility to say "I would like a [majority vote/consensus/poll-format] [comment/emoji-mediated] vote on [Github/Slack/Discord]" and we probably don't want to code every single one of those by hand.

[amyxzhang]

This looks good to me as a first step of common options!

Re @shaunagm's thoughts:

• I don't think we want to be capturing here the different forms of vote aggregation, only forms of vote elicitation. The vast world of voting/social choice theory is difficult to flexibly author and is something better decided by the driver, who also may have a lot more information about voters to make those decisions. The decision of how to count votes and whether something passes is squarely in the scope of what a policy is for, and drivers are where policies are defined. Re - "we probably don't want to code every single one of those by hand" - I totally agree, policy templating is something we want to do but I see that happening in PolicyKit/it is already happening in PolicyKit.
• Abstain is interesting as an option separate from ignoring the vote altogether but I think it should not be included by default because it's more niche.

[amyxzhang]

Oops just saw the request to comment on "customize behavior of close". The options you are describing seem just like options you'd generally want for notify/post_message? Like having a post_message that takes as input an existing message ID that you could say you want to replace/append text/respond to in thread. Could we add these as options to that general function and then call that? Btw I can see cases for when you'd want a silent outcome/secret vote tally too so that should be an option. I think the default behavior for closing should actually just be posting a whole new message (customized by the policy author but with some generic vote count + pass/fail outcome) as this is the most simple.

[gigxz]

Thanks @amyxzhang and @shaunagm . Addressing the comments about "close":

In Loomio, there are 2 steps to completing a voting process: first "closing" the vote, and then (optionally) "sharing the outcome." "Close" means that nobody can cast votes anymore, the voting period has ended, and perhaps the number of votes cast for each option are made visible if they weren't already. "Share outcome" is the notification of the outcome of the vote (here's an example if you want to play around with it in the Metagov Loomio https://www.loomio.org/p/y2C4R3wu/test).

I think these concepts of close vs share outcome are super relevant to your comments @amyxzhang. For Slack emoji-vote, here is how I see these two concepts:

• "close vote" just means that it is made clear to the participants in the channel that they can no longer cast votes on the message. Maybe it displays the final vote count, too. I think editing the post to say "vote closed" or similar makes sense for this.
  • It's more straightforward for processes like Discourse Poll where we can make a call to actually close and lock the vote in the Discourse UI (code). For Open Collective emoji-voting, we prefix the vote thread with [CLOSED] which is pretty ugly, but gets the message across.
• "share outcome" is more open ended, and I think it should be optional. For Slack it could be sending DMs to participants, sending a message to the 'proposer,' posting in a thread, editing the original post, etc. I haven't implemented anything for this in any GovernanceProcesses because I feel like it should be up to the Driver, which has enough context to decide what the outcome should be and who should see it. In the propose-seminar policy, for example, the act of sharing the outcome in the thread is completely separate from the slack.emoji-vote GovernanceProcess–– it's just an action that the policy takes after the vote has been closed.
  • The other approach: Alternatively, we could add a bunch of options to the call to close so that it includes the outcome-sharing post. I'd prefer not to do this because it adds more complexity to the GovernanceProcess and requires us to come up with the outcome-closing options up front.

What do you two think of the "close" vs "share outcome" language, and how they apply to emoji voting?

[gigxz]

... I think we do want people to have the flexibility to say "I would like a [majority vote/consensus/poll-format] [comment/emoji-mediated] vote on [Github/Slack/Discord]" and we probably don't want to code every single one of those by hand.

• I don't think we want to be capturing here the different forms of vote aggregation, only forms of vote elicitation. The vast world of voting/social choice theory is difficult to flexibly author and is something better decided by the driver, who also may have a lot more information about voters to make those decisions. The decision of how to count votes and whether something passes is squarely in the scope of what a policy is for, and drivers are where policies are defined. Re - "we probably don't want to code every single one of those by hand" - I totally agree, policy templating is something we want to do but I see that happening in PolicyKit/it is already happening in PolicyKit.

Suuuper important questions. I think @shaunagm mentioned an idea earlier that Metagov processes could compute an outcome (say, using majority-vote) and ALSO return the raw voting data to the Driver, which might suit both PolicyKit and other Drivers that want to take advantage of plugins that do their own "outcome computation."

For me these questions bring up a tension of whether Metagov is (just) an "API Gateway for governance tools," or if it's something more ("Modular Governance System"?). The modularity/interoperability that is implied by the quoted comment from @shaunagm is really important to the research project overall, I think, and it's not totally clear to me exactly which pieces of this "interoperability" are achieved by Metagov vs by the Driver's "policy templating" capabilities. Hopefully that made some amount of sense 🌀

[amyxzhang]

In the future, yes, we want to move towards the ability to turn vote aggregation code snippets into declarative units you can mix and match. Whether that lives in MG versus PK/drivers - in my opinion, I like the clean split right now of MG as the API connector to governance tools and drivers as the holder/author of a community's governance information and logic. I do think a library of different kinds of governance logic, such as different kinds of vote aggregation logic, is something I want to build into PK directly and aligns well with what PK is meant to be - a general purpose governance authoring tool. It seems non-ideal to have that duplicated in MG and a muddying of purposes so that eventually everything becomes duplicated!

• As an example, PK will have direct access to prior votes, member info and history, roles and permissions, other policies, etc. that are often inputs into aggregation. It would be a big change in terms of what MG has to keep track of to implement, say, liquid democracy aggregation within MG.
• In addition, there are interesting end-user facing aspects on the side of authoring - I want to build in PK ways to author, publish, and fork templates so that it becomes a social, generative library accessible to all users, as opposed to interfaced directly through, say, making a PR to the MG github/searching the MG API docs.

Perhaps this means that other drivers could use PK+MG in concert if they desire, but decide what parts of the PK UI they want to use (including none of the UI but just the libraries)? Related - I would also like to eventually modularize the PK UI so you can select different UI widgets/components depending on what governance tools you are using.

Final thought - we don't have to decide this now. In terms of immediate pressing needs to get these tools out to communities - for now, you can author any kind of vote aggregation in PolicyKit.

[amyxzhang]

Oh and I like @mashton's thoughts around "close" vs "share outcome"!

[shaunagm]

Whether that lives in MG versus PK/drivers - in my opinion, I like the clean split right now of MG as the API connector to governance tools and drivers as the holder/author of a community's governance information and logic. I do think a library of different kinds of governance logic, such as different kinds of vote aggregation logic, is something I want to build into PK directly and aligns well with what PK is meant to be - a general purpose governance authoring tool. It seems non-ideal to have that duplicated in MG and a muddying of purposes so that eventually everything becomes duplicated!

I understand this perspective, but remember that Metagov is meant to support multiple drivers. Keeping the logic solely in PK means that it needs to be duplicated for every driver. I much prefer a model where Metagov provides options that a driver can override, even though that leads to some duplication.

As an example, PK will have direct access to prior votes, member info and history, roles and permissions, other policies, etc. that are often inputs into aggregation. It would be a big change in terms of what MG has to keep track of to implement, say, liquid democracy aggregation within MG. In addition, there are interesting end-user facing aspects on the side of authoring - I want to build in PK ways to author, publish, and fork templates so that it becomes a social, generative library accessible to all users, as opposed to interfaced directly through, say, making a PR to the MG github/searching the MG API docs.

PK could still do all of these things. It would just ignore whatever aggregation MG came up with and perform its own, using the additional information it has available. In this model, MG is never overriding the driver, it's just performing extra work so the driver doesn't have to unless it wants to.

Perhaps this means that other drivers could use PK+MG in concert if they desire, but decide what parts of the PK UI they want to use (including none of the UI but just the libraries)?

Requiring other drivers to use PK seems like a bigger change to the MG architecture than adding some aggregation/tallying logic to core.

[shaunagm]

And I like the separation out of "close" and "share" - these seem like two distinct things.

[amyxzhang]

I agree with your arguments @shaunagm about wanting to avoid duplication. My concern is that the rationale of "not wanting to duplicate things for every driver" can be an argument that applies to many things. My examples about the things that PK can do today is just to say one could argue that other drivers might be interested in these as well (and why not? A policy library sounds like it could be useful generally), and it would be a big change to make them work in MG. If there comes to be more and more duplication between PK and MG due to creeping scope in MG, that would be an unfortunate waste of time IMO that could instead be saved by just letting drivers access PK (certainly not as a requirement to use MG but if there is a desire by them to access a library of policies authored in PK, seems fine? Even separately from this conversation, I think this could be a good idea to break out the UI modular parts from the library parts, which are potentially valuable on their own).

Of course a little bit of tallying logic is not a big deal (though it is trivial enough that it doesn't seem that useful either), but moving towards vote aggregation more generally would certainly be (what I was trying to show with the examples I gave above). If we stop with some simple kinds of tallies, ok fine---though it does still feel muddying to me (because then, why not other kinds of tallies too?)

We can discuss this at length in person tomorrow! :)

[gigxz]

Closing in favor of follow-up issues https://github.com/metagov/gateway/issues/181 https://github.com/metagov/gateway/issues/183 https://github.com/metagov/gateway/issues/184

All of these could be applied to Discord, too, is very similar