Participatory budgeting use case (full)

Metagov Gateway
#1

Use Case Overview
A municipal government decides to implement participatory budgeting (PB) online. The PB process proceeds in three phases: (1) idea collection, (2) project proposal development, and (3) voting.

Actors
Administrators: People who make the rules of the PB process and oversee its implementation
Idea submitters: People who propose projects that could be funded by PB
Budget delegates: People who take project ideas and develop them into feasible project proposals (e.g., design, cost estimate, timeline, etc.)
Voters: People who cast a PB ballot to vote for projects (typically includes idea submitters, budget delegates, and anyone else eligible to participate)

Example User Flow

Trigger: An administrator tells PolicyKit to initiate a PB process

Preconditions:
The administrator has accounts with PolicyKit (or some other driver), Discourse, Loomio, and Open Collective. The administrator already has specified the rules of the PB process in PolicyKit (e.g., who can propose an idea to be funded, who can be a budget delegate, and the rules for voting in the process).

Steps:

  1. After the administrator initiates the PB process, Metagov creates topics on the group’s Discourse. The topics correspond to the project funding themes already stipulated by the administrator in PolicyKit (e.g., transportation, arts, education, etc.).

  2. Idea submitters then propose project ideas in Discourse within the Topics created by Metagov. Each thread is a project idea proposal, and users can like and reply to the thread to discuss the possibilities of the project idea. Example: An idea submitter creates a thread on the “Transportation” topic to propose installing a bench at a bus stop. Other idea submitters then reply to the thread to discuss whether they like the idea of a bench at that bus stop.

  3. Either when the administrator manually directs PolicyKit to move to the next phase of PB, or after a period of time that already was stipulated in PolicyKit when the administrator initiated the PB process (e.g., 2 weeks), Metagov closes the Discourse (users can still view everything but no longer create or reply to threads) and transfers the project ideas (threads) over to Loomio categories (the categories would correspond with the Discourse topics, such as transportation, arts, education, etc.) and threads. Budget delegates then work on the project ideas to develop them into full-fledged project proposals using Loomio’s poll and decision-making features. During this time, some project ideas are eliminated and others are approved to be placed on the PB ballot.

  4. Either when the administrator manually directs PolicyKit to move to the next phase of PB, or after a period of time set in PolicyKit (e.g., 8 weeks), Metagov closes the Loomio discussions and transfers the approved project proposals and their descriptions from Loomio to Stanford PB, creating a PB ballot with the projects already populated. Voters then cast ballots for the projects they want to see funded.

  5. Either when the administrator manually directs PolicyKit to move to the next phase of PB, or after a period of time set in PolicyKit (e.g., 2 weeks), Metagov closes voting on the Stanford PB ballot and transfers winning projects to Open Collective, which updates the budget to include spending on the approved projects.

Other considerations:

  • Throughout each phase of the PB process, perhaps Metagov can track data and send that back to PolicyKit for reporting purposes. Or maybe Metagov just tracks the data and reports it to the administrator? Examples of data to collect and report: Number of idea submitters on Discourse, number of projects proposed in Discourse (e.g., number of threads created), number of projects moved from Loomio to the Stanford PB ballot, number of PB ballots submitted, and the breakdown of votes on the ballot).

  • Is there a way that Metagov could interface with PolicyKit to make the rules of the process easy to select before the administrator initializes PB in PolicyKit? For instance, Stanford PB has a wide range of settings: Size of the budget to be allocated, the window of dates available for voting, how to validate PB voter eligibility, and the voting method. Could Metagov present these options to the administrators either when the PB process is first initialized, or when project proposals are transferred from Loomio to the Stanford PB ballot?

1 Like
#2

Thank you @vincent this is great!

#3

Exciting to see this! Thanks, Vincent.

What if it skipped the Loomio step and just did a proposal in Discourse, with people voting by emoji? Or is it worthwhile to include more platforms?

#4

@ntnsndr we chatted in the meeting about simplifying this, after you left. @vincent mentioned that he was intentionally trying to use as many of the tools as possible when coming up with this use case :slight_smile:

Boiling this down to 3 phases:

  1. Idea submitters submit project ideas
  2. Budget delegates decide which projects to keep, and develop them project proposals
  3. Voters cast PB ballots to vote for projects
  4. Results are exported from PB system into another system

It sounds like phases (1) and (2) can happen on the same platform–– either Discourse or Loomio–– both of which support discussion threads and voting.

So, as promised, here’s a VERY simplified version of this use case. It combines steps 1 and 2, removing the role of “budget delegate.” I’m using the term “governance system” to encompass Metagov and/or PolicyKit.

  1. An admin logs into a governance UI. In the “PB Widget” they can click “Start PB Process.” The system creates a new Category in Discourse called pb-project-proposals. Each topic in this category will be considered a project proposal for Participatory Budgeting. The category has topic voting enabled, so members are allowed to cast a certain number of votes in the category. They can un-cast and re-cast votes any number of times during this period.
  2. Community members on the Discourse can create a new proposal (“topic”), discuss in threads, edit their own proposal, and vote on the proposals. The proposals need to be structured in some way so that we can programmatically pull out the project Title and the project Cost.
  3. After 2 weeks, the governance system locks the pb-project-proposals category on Discourse. It closes all topics, returning votes to users. It selects the top 5 proposals with the most votes. These are the ones that will be voted on in the PB process. The system generates a CSV with information about these 5 proposals specifically formatted to be imported into Stanford PB (title, description, cost). It uploads this CSV to Discourse in a post.
  4. An admin downloads the CSV and uploads it into Stanford PB using their “import projects” button. They set any other configuration in the PB tool. They start the process in the PB tool.
  5. Something (PB tool or governance system) notifies community members that they can cast ballots.

This may be too rigid/simplistic to be actually useful. I’m curious to hear what you think @vincent. I wonder if we can find a use case for something this simple in other (non-city) communities that want to use participatory budgeting.

One problem with my version is that is skips the ‘budget delegate’ step of having a more skilled/trusted group develop full proposals and vote among themselves. Only the admin can “cheat” and make changes to project descriptions or costs in step 4. Another idea is to use Discourse to assign a group of people as “budget-delegate-moderators” who have the power to edit anyone’s proposals during step (2). That seems like a strange way to use moderator capabilities, though, and is very different from having a second phase of budget delegate deliberation.

We could get rid of the CSV thing in steps 3-4 if we add an endpoint to Stanford PB to upload the project list for a new ballot. Then the governance system can do it without human intervention.

#5

@miriam I think this is a good, simpler way to do a PB process. I don’t think it’s necessarily a “problem” to skip the budget delegate step. Instead, in your version, if a community member wants to submit an idea, they just have to submit a well-developed project proposal, so everyone in the community is effectively empowered to be a budget delegate, which I think would work. :slightly_smiling_face:

Perhaps this is a possible use case (just an idea): A twitch streamer has a Patreon and a community of fans. The streamer also has a Discourse set up for the fandom community where everyone interacts. The streamer decides she wants the fans to determine how some of the Patreon money will be used to improve the fan experience, and she runs this simplified version of PB on her Discourse.