This would seem to be a blocker for T359038: Script to migrate current GrowthExperiments config schemas into new structure.

GELevelingUpGetStartedMaxTotalEdits seems like just a plain integer input, nothing fancy. (Based on 5 seconds of looking at usages, please let me know if I'm wrong.)

However, with GELevelingUpKeepGoingNotificationThresholds we have the interesting challenge that this is a configuration that consists of two values, a minimum and a maximum, but only the maximum should be configurable. It seems to be only used in \GrowthExperiments\LevelingUp\LevelingUpManager::shouldSendKeepGoingNotification (unless I missed something).

How do we want to deal with this?

One option (Option 1) I can think of right away, would be to split it up into two PHP config values, and have only the maximum configurable. The upside is that there is no change needed for community config. The downside is that quite a bit of work would be needed for GE.

Another option (Option 2) would be to custom build a control for that in GE, that then only displays the second of those two values as editable in the form, but stores both of them in the JSON. The upside of that is that it mirrors the current behavior of the legacy config. The downside is that we need a custom component coming from GE and wiring in CC to make that possible. (Probably not that much actual vue work, because this is just an integer input, but quite a bit of wiring). Though that is functionality that we want to have eventually anyway.

The last option I can think of (Option 3) would be to put the LevelingUp config into its own Provider and have GE write the form of that completely on its own. The upside is that this maybe needs less work on the CC side, the downside is that we might have quite a bit of extra wiring on the side of GE.

Thoughts?

In T365612#9830113, @Michael wrote:

However, with GELevelingUpKeepGoingNotificationThresholds we have the interesting challenge that this is a configuration that consists of two values, a minimum and a maximum, but only the maximum should be configurable. It seems to be only used in \GrowthExperiments\LevelingUp\LevelingUpManager::shouldSendKeepGoingNotification (unless I missed something).

This already seems a miss-usage of CC2.0; if two config option values have different editing workflows they should probably not be described as an array of integers as that makes it harder to apply different validation rules to each element. An object with min and max properties would be more appropriate.

How do we want to deal with this?

One option (Option 1) I can think of right away, would be to split it up into two PHP config values, and have only the maximum configurable. The upside is that there is no change needed for community config. The downside is that quite a bit of work would be needed for GE.

I think we can use the existing CommunityConfigurationWikiPageConfigReader to do this kind of mapping as we've done with enumerations.

Another option (Option 2) would be to custom build a control for that in GE, that then only displays the second of those two values as editable in the form, but stores both of them in the JSON. The upside of that is that it mirrors the current behavior of the legacy config. The downside is that we need a custom component coming from GE and wiring in CC to make that possible. (Probably not that much actual vue work, because this is just an integer input, but quite a bit of wiring). Though that is functionality that we want to have eventually anyway.

Having a min/max custom control seems appropriate but very far from the level of fine grain work we want to do in the editor at this point. Specially when we still don't know if we want to make the minimum editable.

The last option I can think of (Option 3) would be to put the LevelingUp config into its own Provider and have GE write the form of that completely on its own. The upside is that this maybe needs less work on the CC side, the downside is that we might have quite a bit of extra wiring on the side of GE.

I don't understand what's different from having an own provider and reusing existing "homepage". What would be the new data type? A single integer for max?

In T365612#9834683, @Sgs wrote:

In T365612#9830113, @Michael wrote:

[...]

One option (Option 1) I can think of right away, would be to split it up into two PHP config values, and have only the maximum configurable. The upside is that there is no change needed for community config. The downside is that quite a bit of work would be needed for GE.

I think we can use the existing CommunityConfigurationWikiPageConfigReader to do this kind of mapping as we've done with enumerations.

Mh, that might work. Then the Schema would only include the max-value as a normal integer-input and the provider would add 1 as the min-value before returning it. While in theory wikis could have edited the min-value too by editing the json directly, in practice, this has not happened: https://global-search.toolforge.org/?q=GELevelingUpKeepGoingNotificationThresholds&namespaces=8&title=GrowthExperimentsConfig%5C.json

This seems like the least-effort solution that gets us sufficiently close to the legacy config in all the important ways.

Another option (Option 2) would be to custom build a control for that in GE, that then only displays the second of those two values as editable in the form, but stores both of them in the JSON. The upside of that is that it mirrors the current behavior of the legacy config. The downside is that we need a custom component coming from GE and wiring in CC to make that possible. (Probably not that much actual vue work, because this is just an integer input, but quite a bit of wiring). Though that is functionality that we want to have eventually anyway.

Having a min/max custom control seems appropriate but very far from the level of fine grain work we want to do in the editor at this point. Specially when we still don't know if we want to make the minimum editable.

I would not build a min-max input for this, because we don't actually want the min-input part to be editable via the form. Basically my idea would have been to just reuse an integer input and using extra wiring to to add the min-value to it before submitting.

The last option I can think of (Option 3) would be to put the LevelingUp config into its own Provider and have GE write the form of that completely on its own. The upside is that this maybe needs less work on the CC side, the downside is that we might have quite a bit of extra wiring on the side of GE.

I don't understand what's different from having an own provider and reusing existing "homepage". What would be the new data type? A single integer for max?

The difference between my Option 2 and Option 3 is that in Option 2 we need to build the boilerplate into CC for an extension to inject a single custom control into an otherwise CC-generated form. This is something we want down the line anyway, but probably not trivial to build. But it would allow us to add the LevelingUp configs to some "Other Growth Configuration"-provider that we were considering in a different task.
However, Options 3 would go the different route where we would have a dedicated provider for LevelingUp for which the entire form would be built in GrowthExperiments. That is probably easier to achieve in the CommunityConfiguration side, no "load that other extension control here and handle its events", however would be more complex for GE.

But from the above, Option 1 probably gives us the best value per effort right now.

Change #1036634 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] Config: add missing leveling up options in newcomer schema

https://gerrit.wikimedia.org/r/1036634

Change #1036634 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Config: add missing leveling up options in newcomer schema

https://gerrit.wikimedia.org/r/1036634

For Design review @JFernandez-WMF - the figma design shows that the Newcomer onboarding options are grouped into Newcomer homepage links and Notifications; the current beta Newcomer onboarding options do not display those titles. Do we need any follow-ups on that?

figma design	cswiki beta