Page MenuHomePhabricator

Community configuration 2.0: migrate Special:EditGrowthConfig
Open, HighPublic

Description

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 typeHTMLFormFieldExampleNotes
booleanHTMLRadioFieldGEMentorshipEnabled
intHTMLIntFieldGEMentorshipMinimumAge
textHTMLTitleTextFieldGEHelpPanelHelpDeskTitle
array<int>HTMLTitlesMultiselectFieldGEInfoboxTemplates
array<int>HTMLNamespacesMultiselectFieldGEHelpPanelExcludedNamespaces
array<int>One HTMLIntFieldGELevelingUpKeepGoingNotificationThresholdsThresholds is an array of two numbers, eg [1,7], only the second element is editable
array<object>Several HTMLTitleTextFieldGEHelpPanelLinksEach 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?
TypeDefault control
booleanCheckbox
stringTextInput
numberTextInput[type=number]
objectFlattens properties and shows default control
arrayTBD, pending design/schema revision
refsTBD, probably same as Object
Acceptance criteria
  • Mentorship configuration options are moved to Special:CommunityConfiguration/Mentorship
  • Newcomer hompeage configuration options are moved to Special:CommunityConfiguration/NewcomerHomepage
  • Help panel configuration options are moved to Special:CommunityConfiguration/HelpPanel
  • Suggested edits configuration options are moved to Special:CommunityConfiguration/SuggestedEdits
  • ...

Details

TitleReferenceAuthorSource BranchDest Branch
Draft: Add GrowthExperiments Newcomers homepage schemarepos/growth/community-configuration-example!12sgimenoschema-referencesmain
Draft: Add GrowthExperiments Mentorship schemarepos/growth/community-configuration-example!10sgimenoschema-mentorshipmain
Customize query in GitLab

Event Timeline

KStoller-WMF moved this task from Backlog to Up Next on the Growth-Team board.

I split the actual engineering work that is asked for in this task into subtasks. This is because not all parts of Special:EditGrowthConfig need to be migrated at the same time and by the same person.

@KStoller-WMF As a followup to your Slack question, I added those newly filled subtasks into the 10th sprint. I consider this task to have the role of an umbrella task (kind of an epic, but shorter) - I'll leave it up to you whether you want to pull it onto the sprint board as well or leave it here.