The goal of this task is to make use of CC2.0 extension to migrate the current logic of SpecialEditGrowthConfig. Since CC2.0 is not ready yet for production use this task can serve as another use case study for CC2.0 specifications
Status quo
The feature configurations that live in Special:EditGrowthConfig are one of the main GrowthExperiments consumers of community configuration. In particular the form writes values in two configuration files: MediaWiki:GrowthExperimentsConfig.json and MediaWiki:NewcomerTasks.json.
EditGrowthConfig page uses the MW OOUI HTMLForm to generate all the form fields for a given configuration (or set of configs). JSON data types have been mapped to corresponding HTMLFormFields in standard and non-standard ways. See:
| Data type | HTMLFormField | Example | Notes |
| boolean | HTMLRadioField | GEMentorshipEnabled | |
| int | HTMLIntField | GEMentorshipMinimumAge | |
| text | HTMLTitleTextField | GEHelpPanelHelpDeskTitle | |
| array<int> | HTMLTitlesMultiselectField | GEInfoboxTemplates | |
| array<int> | HTMLNamespacesMultiselectField | GEHelpPanelExcludedNamespaces | |
| array<int> | One HTMLIntField | GELevelingUpKeepGoingNotificationThresholds | Thresholds is an array of two numbers, eg [1,7], only the second element is editable |
| array<object> | Several HTMLTitleTextField | GEHelpPanelLinks | Each link has title, text, id |
Some of these mappings require ad-hoc logic to set the field value from the source data and to process the submitted data before storing it in JSON.
Open questions
-
Should the Growth config keep storing configurations in two pages, more, less? What's the split criteria?
Growth config will be kept in separate config pages, each page will have a dedicated editor. Split criteria is by design, see Figma designs
-
What's the expectation from a product pov of the feature grouping and discovery?
Each set of themed configuration options will live in a separate page and be edited through a different editor. Grouping options on the same editor form is possible but left out of the scope of the MVP, see T358221
-
What's the expectation from a design pov of the field mappings?
| Type | Default control |
| boolean | Checkbox |
| string | TextInput |
| number | TextInput[type=number] |
| object | Iterates over properties and shows default control for each prop type |
| array | Iterates over data elements if any and shows default control for each prop type |
| enum | A set of radio buttons, T362685 |
Acceptance criteria
- Mentorship configuration options are moved to Special:CommunityConfiguration/Mentorship
- Newcomer hompage configuration options are moved to Special:CommunityConfiguration/NewcomerHomepage, T360473
- Help panel configuration options are moved to Special:CommunityConfiguration/HelpPanel, T360472
- Correctly process GEHelpPanelPostOnTop, T364053
- Suggested edits configuration options are moved to Special:CommunityConfiguration/SuggestedEdits, T360471
- Support float numbers, T363733
Nice to have
- Script to migrate current configs, since it may include (in follow-up if appropriate) the data migration for GEHelpPanelPostOnTop, T359038