META-ISSUE: Metagov Prototype enhancements

[gigxz]

This is a meta-issue for the Big™️ things that we've considered adding to the Metagov Prototype, but were deferred from the initial prototype phase (Jan-June 2021).

Metagov Enhancements

Ideas for how to make Metagov Prototype a more useful tool. Hypothesis is that these enhancements will increase chances of adoption. We're early in the learning phase!

These are split into two categories: enhancements that are driven by "Driver DX" and enhancements that are driven by "Plugin DX."
"Driver DX" is the developer experience of creating a Driver. It concerns the interface and functionality exposed to the Driver from Metagov (the leftmost arrow), also known as the "Metagov API."
"Plugin DX" is the developer experience of creating a Plugin. It concerns the interface and functionality exposed to the Plugin author from metagov-core.

Driver Developer Experience

The "Driver Developer" is creating a driver that uses Metagov, or updating an existing piece of governance software to use Metagov (ex PolicyKit, Kybern). This person is (1) hitting the Metagov API from the Driver code, (2) deploying Metagov, (3) deploying updates to Metagov (ie migrating to latest version of metagov-prototype which could include plugin changes, new plugins, or core changes).

• Add plugin abstraction for ”notifying users.” Discussion: Feature ideas to enable "communicative" governance systems #38
• Add core capabilities for monitoring/logging, so that the Driver can expose tools for governance oversight. Discussion at Collecting requirements for Metagov "monitoring" features #37
• Create Metagov client libraries. Issue: Create a client library in Python for Metagov #30
• Expose jsonschemas for each action/process so that the Driver (PolicyKIt) can implement no-code policy building, client-side validation, autocomplete, etc. Issue: Expose endpoints for listing available actions, processes, events and their schemas #31
• Make it easier to deploy Metagov. (Dockerize it). Issue: Dockerize metagov service #32
• Improve Community management API (/community endpoints). Right now there is not enough information to create a robust community mgmt UI on the Driver side. Metagov should expose plugin config schemas.
• [🔀 ARCH] Re-consider Metagov-as-a-library (code that you compile into your Driver application) vs Metagov-as-a-local-service.
• [🔀 ARCH] User identity: make it easier for the Drivers to govern communities across multiple platforms, by providing some infrastructure around identity. Discussion: Implementing a minimal identity (meta)system #34
  • Add core abstraction for performing an action on behalf of a user. (Especially important for supporting policies that govern actions using a revert-and-decide approach.)
  • Add concept of roles/relationships/groups in Metagov, or some concept of a generic "user attribute."
• Add plugin abstraction over governance processes, for example "voting process" that can be swapped out. This lets the generic driver swap voting processes.

Plugin Developer Experience

The "Plugin Developer" is authoring a Plugin to connect to some platform(s) or implement some governance process(es). They are running Metagov locally in order to develop their plugin in this repo under metagov-prototype/metagov/metagov/plugins.

• Add scheduler, to support "listener" plugins (or governance processes) that need to poll an external service. Issues Add task scheduling system to metagov-core #19 and Add option to invoke Callback URL each time a GovernanceProcesses outcome changes #33
• Add support for "widget plugins"?
• [🔀 ARCH] Re-consider: should we make the plugins non-Django-specific?
• [🔀 ARCH] Re-consider: can we make it possible to develop plugins independently from the metagov django service? (ie make some metagov library that authors can import and use to create plugins. in a metagov deployment, you'd be able to pull in plugins from separate repos.)

Community Admin UX

The "community admin" is the member of a community who sets up some part of the governance infrastructure. This UX will vary widely depending on which Driver is used. If PolicyKit is used, the "community admin" is going to policykit.org and installing PolicyKit to their community, and configuring Metagov through the PolicyKit settings screen.

• Add support in Metagov for automatically "creating" organizations in OpenCollective/Loomio/SourceCred for a brand new community. Metagov would be some bot user that owns the orgs. See https://discourse.metagov.org/t/metagov-as-software-bundle/93

Productionizing Metagov

Ideas for making Metagov "production-ready."

• Figure out how upgrades will work. If there's a running instance of Metagov and we want to update to add a new plugin (requires running Db migration for proxy model), update a plugin in a way that changes the API for example changing input/output of an action (yikes! Driver will need to change at the same time). Versioning the Metagov API / versioning plugins.
• Security - ensuring separation of data between communities
• Test coverage and CI.
• A loooot more. Come back to it.

[thelastjosh]

This is really good. I'll add "package multiple services + installations into a shared, simplified install" to the enhancement list. This was originally Phase 2.

…

On Wed, Apr 14, 2021 at 2:37 PM Miriam Ashton ***@***.***> wrote: This is a meta-issue for the Big™️ things that we've considered adding to the Metagov Prototype, but were deferred from the initial prototype phase (Jan-June 2021). Metagov Enhancements Ideas for how to make Metagov Prototype a more *useful* tool. Hypothesis is that these enhancements will increase chances of adoption. We're early in the learning phase! - User identity in Metagov, maybe roles, maybe relationships between people, maybe groups - Account linking across platforms - Expose schemas through the API (so PolicyKit can support no-code policies by generating forms from jsonschemas, for example) - Better more consistent error handling. Define an error response that is consistent, so the Driver can handle them and potentially surface them to the user. - Monitoring / logging (*oversight*) - Add plugin abstraction for ”notifying users” (*communicative governance*) - Add support for "widget plugins" - Supporting polling (in addition to webhooks) for "listener" Plugins - Plugin composition - Approach for "governing metagov" - Add abstraction over governance processes, for example "voting process" that can be swapped out Productionizing Metagov Ideas for making Metagov "production-ready." - Figure out how upgrades will work. If there's a running instance of Metagov and we want to update to add a new plugin (requires running Db migration for proxy model), update a plugin in a way that changes the API for example changing input/output of an action (yikes! Driver will need to change at the same time). - Versioning APIs - Security - ensuring separation of data between communities - Test coverage and CI. - A loooot more. Come back to it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACHA5PCDFT2QRTCTW7H65O3TIXOFHANCNFSM42554JKQ> .

-- http://www.joshuatan.com/research/

[thelastjosh]

I've written a new use-case focusing on the "software bundle" enhancement above: https://discourse.metagov.org/t/metagov-as-software-bundle/93/

Posting Slack conversation here, for context.

Miriam Ashton Apr 14th at 2:59 PM
@josh I feel like Slack might be easier than git –– can you say more about this comment?
I’ll add “package multiple services + installations into a shared, simplified install” to the enhancement list. This was originally Phase 2.
All plugins are included with metagov; what do you mean by “packaging” services? Install to what? It may have been originally planned for phase 2, but that was before we had any idea what metagov was going to be, so I’m not sure if it still applies :thinking_face:
4 replies

Josh 1 day ago
Yeah fair enough, the basic idea was that installing Metagov would automatically create a SourceCred install, a PolicyKit install, an OpenCollective registration, a Loomio registration, etc.

Miriam Ashton 1 day ago
Oh wow I see. There are certain things the people just have to do manually, because auth and security 🙂
Like a human needs to go into OpenCollective to create a new collective, and they need to create a new API Key for metagov in the Open Collective UI. We can’t magic those things away sadly.

Josh 1 day ago
We can get started with things like SourceCred and PolicyKit where we have more control. Then we can negotiate with services like Open Collective to build support for an automated placeholder registration. If it helps supplement their pipeline, I think we may able to convince them to support that.

Shauna Gordon-McKeon 22 hours ago
Josh can you explain what you mean by "installing Metagov would automatically create a SourceCred install, a PolicyKit install, an OpenCollective registration, a Loomio registration, etc."
Do you mean that when I, a server host, install metagov, it would create accounts on SC, PK, etc? Or that when a user creates a community on my server it would automatically create other communities?
Maybe you could explain by writing out a super simple use case? Just, explain what you imagine happening as a narrative.

[shaunagm]

I feel like the community wasn't super enthusiastic when I brought this up before, but I think we should do what we can to support monitoring. Not sure how much of that will be in Metagov vs individual drivers, but a topic to at least think about here.

I know that's on your other doc, but I'm adding a comment here as this is, I think, the canonical place to track suggested enhancements?

[gigxz]

Add core capabilities for monitoring/logging, so that the Driver can expose tools for governance oversight.

This is in here! I am enthusiastic about it, though the implementation details are still hazy to me. I wrote that the Driver would expose tools but it could be Metagov as well. Yeah I think we should use this as a place to track enhancements because it is more public. (Actually, I'd prefer if it was somewhere multiple people can edit. Let me know if you have a suggestions/preference for where to track these things).

[thelastjosh]

I think we should distinguish between monitoring/logging of tools and their configurations (which I think we should refer to as "logging") and integrations with specific packages+software that track community behavior and present it to communities, in the sense of ModPol "monitors". They should both be target enhancements, but the latter can be accomplished through targeted integrations and/or through collaborations with data scientists + academics like Seth.

[shaunagm]

I like your terminology. I think we ought to have an in-depth discussion about monitoring before settling on the ideal way to facilitate it and incorporating it into either our short or long term plans.

[gigxz]

Agreed. In the mean time, here's a placeholder discussion space for monitoring: #37