Voting on features in Discourse, weighted by SourceCred and OpenCollective

Metagov Gateway
#1

This use-case is inspired by the Webpack Vote and Prioritize application which lets community members vote on features, and gives more voting power to members who are backers or sponsors on OpenCollective.

OpenXYZ is an open source development group. They use GitHub for development, Discourse for community discussions, SourceCred for tracking value creation, and OpenCollective for accepting financial contributions.

The OpenXYZ core team gets a lot of feature requests, and wants community input on how to prioritize features. They decide to put it up to a community vote each quarter. They decide to use dot-voting, where the number of votes someone gets is based on (1) the amount of value they have created in the OpenXYZ community, as measured by SourceCred, and (2) whether or not they are a financial Backer or Sponsor in OpenCollective.

Example User Flows

1: Casting a Vote

User

Shira is a developer. She has gained 12 Cred by contributing to the OpenXYZ GitHub repo and participating in the OpenXYZ Discourse forum.

Trigger

Shira wants to vote on which features should be prioritized by the core team for Q3.

Preconditions

  • The OpenXYZ group has set up a SourceCred instance which is linked to GitHub and Discourse
  • The Discourse server has the discourse-voting plugin installed. The discourse-voting plugin is configured to set vote limits by fetching some value from the Metagov server (requires code changes to plugin, which uses Discourse Trust Levels to set vote limits)
  • The OpenXYZ core team has created a category called “Features,” and each topic listed in it corresponds to one feature that can be voted on.
  • The OpenXYZ group has set up a Metagov Prototype instance which was previously used to connect the voting plugin to SourceCred

Steps

  1. The user, Shira, logs into Discourse
  2. She navigates to her profile and sees that she has 6 DiscourseVoting votes available to cast. The system indicates that this is correlated with her Cred score which is currently 12.
  3. She navigates to the “Features” category
  4. She clicks on one of the features she thinks is important and clicks “vote” (enabled by discourse-voting plugin). She can repeat this step until she is out of votes.

2: Configuring the System

User

Zay is on the OpenXYZ core team. They have access to install Discourse plugins. They have access to configure modules on the Metagov Prototype.

Trigger

After discussion with the core team, Zay is tasked with setting up the feature voting mechanism outlined in the description.

Preconditions

  • The OpenXYZ group has set up OpenCollective and a SourceCred instance which is linked to GitHub and Discourse
  • The OpenXYZ group has set up a Metagov Prototype instance that has already been linked to SourceCred and OpenCollective

Steps

  1. Zay installs the discourse-voting plugin into the OpenXYZ Discourse server.
  2. Zay logs into the Metagov system to configure the voting behavior
  3. They install the DiscourseVoting module which has some configuration option for vote limits
  4. They configure the module to be dependent on SourceCred and OpenCollective.
  5. They configure the vote limit to be equal to the evaluation of some code snippet: Maximum(User.cred * 0.5 + (User.oc_backer ? 10 : 0) + (User.oc_sponsor ? 100 : 0), 1)
  6. The go back to Discourse and set up the Features category, select “can vote” which appears from the plugin, and add each feature as a new topic.

Comments

  • In this use case, one of the underlying “governance libraries” is the discourse-voting plugin, which of course is specific to Discourse. We would fork this plugin and turn it into a Metagov-compatible “Module” which has one “integration point”: the vote_limit per user. The value added by using the Metagov plugin fork instead of discourse-voting plugin directly, then, is that you are able to configure the vote_limit based on any user information that exists in the Metagov system.
  • What happens to votes as a user gains or loses Cred?
#2

Responding to just a small piece of this:

  • What happens to votes as a user gains or loses Cred?

This is something that’s come up on Concord (my governance project), where decisions are being made over time, and by the time a decision is made the context in which it’s being made may have changed. A few ways I’ve tried to deal with that:

  • “freeze” the participants in a decision to the status they were at the start of the decision-making process and hope for the best (honestly not a bad idea in prototype mode)
  • make sure communities can withdraw or restart a decision-making process if changing context makes it unusable
  • give communities the ability to decide whether to freeze, withdraw, or auto-restart by default, depending on what’s changed

This is one of the toughest questions I’ve encountered, though.