Growth/Community configuration/en



This page describes the Growth team's work on the "community configuration" project. This page contains major assets, designs, open questions, and decisions. Most incremental updates on progress will be posted on the general Growth team updates page, with some large or detailed updates posted here.

Current status

 * 2021-02-11: work begins to plan project
 * 2021-04-14: the configuration editor was made available on the beta wikis
 * 2021-04-24: last tests, deployment to pilot wikis
 * 2021-05-07: configuration of Newcomer tasks added to the form
 * Next: deployment to all wikis

Summary
The Growth team's features are unique because they require community input before they can be deployed to new wikis. Before deploying, communities need to indicate things like the location of their list of mentors, the help links they want displayed in the help panel, and the templates that should be used to find newcomer tasks. To set up these features or to make any change to how the features behave, communities have had to create a Phabricator task for the Growth team to make a change to the code (see this page for the process). This slowed down how quickly the features could be deployed to new wikis, and how often communities could make alterations.

To solve this problem, the Growth team is building a way to allow communities to set up and control the configuration of Growth features themselves. Administrators will be able to use a form on their wikis to change the settings of the Growth features for all users. This form is available at.

While this will help communities with the Growth features, this idea also has potential to be used with other WMF features. Rather than a "one-size-fits-all" approach, perhaps we'll be able to expose configurations so that communities can make sure that features fit their culture and needs.

How it works


The configuration is stored in a JSON page in the MediaWiki namespace. In order to let non-tech savvy community members to manage the configuration as well, we created a custom form over the JSON blob with the configuration itself. That way, community members don't need to know how to edit JSON in order to change the configuration, while keeping the configuration stored in a format that's easily understandable by machines.

Only administrators and interface admins will be able to edit the form.

The form validates that the information being changed fits the format required.

Be careful: When changes are made via the form, it will immediately affect all users with the Growth features, which is thousands of users. Therefore, it's important to be careful and deliberate when making changes.

Because the form edits a MediaWiki page, it inherits some essential features that each MediaWiki page has:

Communities need to develop their own processes for debating and forming consensus on changes to make. It's similar to deletion discussions: though one admin can delete an article, wikis still have processes to decide whether an admin should do it.
 * Changes made on the form leave edit summaries to the JSON page.
 * It is possible to revert configuration to its older version from the JSON page.
 * Discussion about changes can happen on the JSON page's talk page.

Included configuration variables
While the form does not allow communities manage all configuration variables, it exposes the configurations that would affect user experience. For instance, we don't expose the configuration for which database cluster is used by the features. As part of T275086, we decided on a list of configuration variables that we want to allow to be managed on-wiki. We put the list of variables in a spreadsheet (Google Spreadsheets).

Open questions
Community configuration is a new idea that we think will help both communities and WMF. But there are still some open questions that we'll learn about as we speak with communities and as they begin to use the feature:

Please share your feedback with us!
 * Will communities develop consensus before making changes, or will individuals make changes unilaterally?
 * Will restricting the editing to administrators and interface admins be the right level of restriction?
 * Will we need some kind of delay before configuration changes are made, so that a quick series of changes (or edit war on the form) don't cause a very disruptive experience for newcomers?