Review and revise voting mechanism software milestone

[jennymith]

This issue references issue #107 and feedback from the Stacks Foundation Grants Committee:

"Voting Proposal

M1 of the Community Voting Mechanism might start with a handful of voting mechanisms they want to consider.

M4 of making it open source software - who will be building that? I see that Foundation Research Scientist Jude Nelson is listed here as a technical contributor, has he agreed to a set number of hours for this project? I know he is very busy and want to make sure there is a technical reviewer included in this grant who can commit the necessary time to the deliverables outlined above. If he is not available, would you be able to scope with someone else? Or remove the technical components of the proposal? It’s a lot of work to build - so could it start as non-software first? Especially for $450."

To resolve this feedback, @jennymith will do the following:

• [x] Review and revise milestone 4
• [ ] Share with the Governance Working Group for confirmation by 11/12

[HaroldDavis3]

@jennymith Do you think we'll continue with Blocksurvey for now? We may be able to save Jude some time by combining Blocksurvey & Policy KIt. Though its built to fit around Discord or Slack like platforms, the important Stacks auth based quorum & KYC features Jude was concerned about may be possible with integrating PolicyKit with either Blocksurvey or even Friedger's OI chat, as matrix has a bridge for discord:

In order to install PolicyKit to a community, there must be an authentication workflow, such as OAuth, for at least one admin or mod account to give access to PolicyKit so that it may govern a broad set of actions, including privileged ones. The platform integration must also specify ways to send messages to users on the platform. For example in Figure 5, we message users to solicit votes from the jury. In order for PolicyKit to govern actions, it must know what platform actions are possible; these are specified via the creation of PlatformAction classes. Actions typically are carried out via web API endpoints provided by the platform that are then made available through an execute() method in the action class and undoable via a revert() method. Finally, the integration must incorporate a listener to listen for user actions on the platform as well as a listener for votes on a notification message. For instance, votes could be recorded via an emoji reaction or a reply to a notification message.

Note the date_time trigger for an action in the policy function. Works nicely with some of the constraints & quorum thing Jude presented.

Just brainstorming after lil research when seeing this issue. Should we reach out to policy kit team or Friedger, Harini & Wilson for guidance?

[jennymith]

Hey @HaroldDavis3 I think this is a great idea! Looks like you've already got a head-start on the actual project. Perhaps this integration could replace our original milestone (M4) to build voting open source software from scratch?

I haven't thoroughly reviewed the paper, but my one question is whether PolicyKit would be able to accommodate different voting mechanisms beyond pass/fail?

[jennymith]

As for revising M4, I do think we should take out the open source software expectation and just focus on testing and selecting a voting mechanism that works for the community. I propose that instead of building software by Q1 2021, we set a goal to identify a voting solution (like PolicyKit or something similar).