Amendment processes and change mechanisms

This post is an exploration of an expected feature of Metagov: amendment processes for modifying existing governance systems in Metagov. I’ve broken it up into a family of use-cases and user flows around amendment. But it’s also an exploration of the (currently under-specified) type/module system for Metagov. In what follows, a module (in bold) is an intermediate service/plugin that converts API information from a set of related services and provides a unified API interface and configuration interface for interacting with those services.

Minor module change within a single module

A user in a community changes the configuration of a single module, e.g. converts an anonymous Loomio voting system to non-anonymous Loomio voting system.

  1. A user authors a policy proposal to change the Voting module (e.g. a XML config file) via the Metagov Core module.
  2. The proposal passes a validation check against the Metagov Core module that Voting is installed in the current instance.
  3. The proposal passes a validation check against the Metagov Core module that the proposal is a valid configuration of the Voting module.
  4. Depending on the parameters of the Proposal module, the proposal is then discussed via a Discussion module (or directly in the platform).
  5. That proposal is fed to a Voting module.
  6. The community votes.
  7. The outcome of the vote is then fed to the Metagov Core module, and implemented for the community.

Medium system change (replace one module with another “of the same type”)

For example, replace the Voting module with a Voting’ module that exposes more options and configurations but has the same input/output types.

Medium system change (replace one program with another “of the same module”)

For example, replace running a vote in Loomio with a vote in qv.qeek.sg withi. This should be directly supported by the Voting module.

  1. Metagov maintains a list of all well-defined abstract modules (e.g. Voting, Identity, Reputation). Modules can be thought of as connectors that connect external programs (e.g. Loomio, BrightID) to concrete realizations of the module system.
  2. Metagov maintains a list of programs that “connect” the abstract modules to a concrete realization.
  3. Each concrete realization is configurable by at least the configurable parameters specified in the abstract module.

Major system change (several modules + logical connections between them):

TBD.

Revolution! a.k.a. uninstall / delete

  1. Export all existing data to a CSV.
  2. Uninstall and delete the current Metagov instance and all Metagov modules (but not necessarily the underlying platform).