We do have enabled and safe available experiments already exposed on th deployment page.

Grafana Mimir handles experiments & deprecations rather nicely: https://grafana.com/docs/mimir/latest/references/configuration-parameters/#parameter-lifecycle

I also love that they include a Prometheus metric to show which deprecated & experimental configs are in use, with associated log warnings.

From the Coder dashboard, an admin can see what experiments are turned on for their deployment

As @matifali shows above: we already have this, so I'll consider this done unless there are other requirements.

From the Coder dashboard, an admin can see what experiments are available (including * to turn them all on)

@bpmct @matifali to clarify: do we need to be able to activate experiments at runtime? If not, will it be sufficient to link them to https://pkg.go.dev/github.com/coder/coder/v2/codersdk#Experiment? IMHO we should probably maintain a separate docs page listing and explaining all the experiments; it'll be a bit less jarring then jumping to Go docs.

A separate docs page sounds fine but keeping it manually updated will be cumbersome and I am sure it will drift. If we can auto generate the experiments docs that's perfect.

Also we can then link to the docs page from within the dashboard.

About enabling experiments from the UI, currently it is not possible as we need a restart of coderd. We may need a roadmap and RFC if and how we want to support changing configuration without restarting.

Thanks for confirming @matifali 👍 I didn't see a mechanism for enabling experiments at runtime.
Runtime changes could be a valuable feature, it's probably worth exploring.

A separate docs page sounds fine but keeping it manually updated will be cumbersome and I am sure it will drift. If we can auto generate the experiments docs that's perfect.

Also we can then link to the docs page from within the dashboard.

👍

@matifali I think I'll keep the docs update for a separate PR, if that's ok?
We don't have that many experiments, and our current docs are probably fine for that.

I am ok both ways. We don't need to necessarily write docs.

We can choose between the two,

1. Write docs and link to them from within the dashboard
2. Give an overview or small description about what an experiment does within the dashboard.

The purpose is to increase discovery of available experiments so we get more users to try them out.

Yeah I agree it's more suitable to do as a separate PR.