Change Details

Growth features require wiki-specific configurations, i.e. it is not just push-button to deploy to a new wiki. They use links to local help pages, local templates, mentor lists, etc. For this reasons, as we deploy to many more wikis, we need to streamline the process of configuring each wiki. We will use Wikidata to set up a default configuration for each wiki, but many communities may wish to improve or otherwise alter the configuration with better links, templates, etc. We don't want to do new deployments to handle those changes. Furthermore, certain parts of the Growth feature set //can't// be turned on until communities have taken certain actions, like set up a mentor list. **Therefore, here is our idea:** * The features can be deployed to groups of wikis, but in "dark mode". * They're dark until certain configurations have been set, which, once populated, turn the features on. * We can set those configurations with defaults from Wikidata, thereby turning the features on. * Parts that require community input (e.g. question asking on the help panel and mentorship module) stay dark until the necessary configurations for those are put in by community members. * The configurations would all be stored on some on-wiki page that moderately technical community members could edit. **We have these open questions:** * How would community members populate and edit the configuration? Perhaps we wouldn't want them to edit JSON directly. The comments below mention an idea to make a Special page with a form for the purpose. * Which community members would be able to make edits to the configuration? Would this system make it possible for a single community member to essentially turn off the entire feature set by removing the values in the configuration? Or to easily break it by accident? * For the purposes of our A/B tests, it's important to know exactly when features were and were not being shown to users. How would we do that with this system? Relatedly, would it be possible to tell in aggregate which features are and are not turned on in which wikis? * We think that communities may need to take additional time to get set up for the question-asking part of the help panel and for the mentorship module. Do we need to do work to de-couple those elements from the features that they sit in, so that they can be turned on separately? * Is it important to automatically populate configurations with defaults from Wikidata, or should we just do that manually for each wiki?

Growth features require wiki-specific configurations, i.e. it is not just push-button to deploy to a new wiki. They use links to local help pages, local templates, mentor lists, etc. For this reasons, as we deploy to many more wikis, we need to streamline the process of configuring each wiki. We will use Wikidata to set up a default configuration for each wiki, but many communities may wish to improve or otherwise alter the configuration with better links, templates, etc. We don't want to do new deployments to handle those changes. Furthermore, certain parts of the Growth feature set //can't// be turned on until communities have taken certain actions, like set up a mentor list. **Therefore, here is our idea:** * The features can be deployed to groups of wikis, but in "dark mode". * They're dark until certain configurations have been set, which, once populated, turn the features on. * We can set those configurations with defaults from Wikidata, thereby turning the features on. * Parts that require community input (e.g. question asking on the help panel and mentorship module) stay dark until the necessary configurations for those are put in by community members. * The configurations would all be stored on some on-wiki page that moderately technical community members could edit. **We have these open questions:** * How would community members populate and edit the configuration? Perhaps we wouldn't want them to edit JSON directly. The comments below mention an idea to make a Special page with a form for the purpose. * Which community members would be able to make edits to the configuration? Would this system make it possible for a single community member to essentially turn off the entire feature set by removing the values in the configuration? Or to easily break it by accident? * For the purposes of our A/B tests, it's important to know exactly when features were and were not being shown to users. How would we do that with this system? Relatedly, would it be possible to tell in aggregate which features are and are not turned on in which wikis? * We think that communities may need to take additional time to get set up for the question-asking part of the help panel and for the mentorship module. Do we need to do work to de-couple those elements from the features that they sit in, so that they can be turned on separately? This is currently subtasked in {T248193}, but may be able to be closed. * Is it important to automatically populate configurations with defaults from Wikidata, or should we just do that manually for each wiki?

Growth features require wiki-specific configurations, i.e. it is not just push-button to deploy to a new wiki. They use links to local help pages, local templates, mentor lists, etc. For this reasons, as we deploy to many more wikis, we need to streamline the process of configuring each wiki. We will use Wikidata to set up a default configuration for each wiki, but many communities may wish to improve or otherwise alter the configuration with better links, templates, etc. We don't want to do new deployments to handle those changes. Furthermore, certain parts of the Growth feature set //can't// be turned on until communities have taken certain actions, like set up a mentor list. **Therefore, here is our idea:** * The features can be deployed to groups of wikis, but in "dark mode". * They're dark until certain configurations have been set, which, once populated, turn the features on. * We can set those configurations with defaults from Wikidata, thereby turning the features on. * Parts that require community input (e.g. question asking on the help panel and mentorship module) stay dark until the necessary configurations for those are put in by community members. * The configurations would all be stored on some on-wiki page that moderately technical community members could edit. **We have these open questions:** * How would community members populate and edit the configuration? Perhaps we wouldn't want them to edit JSON directly. The comments below mention an idea to make a Special page with a form for the purpose. * Which community members would be able to make edits to the configuration? Would this system make it possible for a single community member to essentially turn off the entire feature set by removing the values in the configuration? Or to easily break it by accident? * For the purposes of our A/B tests, it's important to know exactly when features were and were not being shown to users. How would we do that with this system? Relatedly, would it be possible to tell in aggregate which features are and are not turned on in which wikis? * We think that communities may need to take additional time to get set up for the question-asking part of the help panel and for the mentorship module. Do we need to do work to de-couple those elements from the features that they sit in, so that they can be turned on separately? This is currently subtasked in {T248193}, but may be able to be closed. * Is it important to automatically populate configurations with defaults from Wikidata, or should we just do that manually for each wiki?