Discuss user workflow for enabling Plugins

[gigxz]

There are several ways plugins can be "enabled" for a community. In the code, "enabling" a plugin means creating a new Plugin model instance and passing it a valid "config." Possible human interventions required to enable a given Plugin:

1. User must generate a new API key on some other site, and copy-paste it into the Driver (Open Collective, Discourse, Loomio, MailGun)
2. User must copy the Metagov-generated Webhook URL from the Driver, and register it with an external platform (Open Collective, Discourse, Loomio)
3. User must consent to the installation of a Metagov bot through on OAuth2 flow (Slack)
4. User must input some URL or key to identify the external system (not an access key) (SourceCred)
5. User must input manual configuration values that affect how the Plugin should behave (Randomness Plugin)

The pattern we see so far is that plugins will either require 1+2 OR 3. 4 and 5 are basically the same, but I separate them out because they may have different implications for how we handle the Config.

IF the Driver exposes a way for its users to enable/disable Metagov Plugins for communities, then it must have some user interface for guiding users through the above 3 mechanisms (and maybe others). Currently PolicyKit has an auto-generated form where users input the raw config values, with no guidance as to how to get the API keys or set up the webhooks.

Discuss....

1. How can we make the plugin-enabling workflow less clunky?
2. What is the responsibility of Metagov vs the Driver when it comes to developing user interfaces for configuring a community?
3. Should we guide Plugin developers to using plugin Config for behavior (5), and instead define Actions for modifying Plugin behavior? (Related: to which degree should the Config be governed? Should it be possible to change the Config over time? If the Config is only used for Plugin activation and access, then we maybe don't need fine-grained controls over each config field, etc.)