Does Metagov need to have a UI (yet)? about gateway

[shaunagm]

I think I said this during our meeting last week, but to reiterate: while a UI would be nice to have in the long run, I don't think it's necessary just yet. All our use cases are either going to override whatever UI metagov implements (Kybern, PolicyKit) or don't need a UI because they're a single community with terminal access to metagov itself (Dada). Unless a new use case comes up where a Metagov-implemented UI is important, I say kick this to the backburner.

[amyxzhang]

Overall agree with @mashton on this. I think most drivers would want to surface metagov to end users using their own existing UI, or have no UI at all (no end user input) for connecting to metagov. Any docs would be geared towards driver and plugin authors, not end users.

[gigxz]

my guess is that we still do not need a UI beyond the existing config UI in Django

I would argue that we don't need the Django config UI, either. So there is NO web component to metagov, it is strictly a backend service. The Driver–– whether that's PolicyKit, Kybern, or Dada–– can configure it's own metagov instance by making a request to the /community endpoint. See #11 for an overview of how that works.

In the case of PolicyKit-as-Driver, PolicyKit would need to expose some interface to let the community admin (1) select which plugins to (de)activate, (2) input the config for each activated plugin.

In the case of Dada-as-Driver–– or some platform that is just using metagov to govern a single community–– it can make a one-time request from Dada to create and configure the community (e.g. PUT /community { "name": "dada", "plugins": [ ... ] }). No UI component is necessary.

[thelastjosh]

I would argue that we don't need the Django config UI, either. So there is NO web component to metagov, it is strictly a backend service.

I am okay with that in general, but the Django config UI (or just some sort of minimal UI) seems quite useful for testing purposes and for communicating what Metagov does to new people. In principle, Metagov Core should be more of a backend service that lets the driver or the platform decide on the UI.

[gigxz]

Agreed it's good to have some UI for communication. I think the existing swagger/redoc should be able to communicate what Metagov does, in combination with the Readthedocs.

For example the "create a new community" or "configure plugins for an existing community" can be explained with https://prototype.metagov.org/redoc/#operation/community_update, it just needs some more narrative. And generating docs for the plugin config schemas would be nice as well (both doable! I already have this infrastructure set up). It's also useful for testing purposes (in local development only, since the endpoints of deployed metagov instances should be restricted to local traffic).

[gigxz]

Ok, that's consensus so I'll close this issue.

Decision

No, Metagov does not need a UI yet. It would be nice to have in the long run, but it's not necessary for any of the current or upcoming use cases.