Quoting T360472#9764689, which are related to this task:

In T360472#9764689, @Sgs wrote:

I'm doubting on the best approach to support the new data schemas for GEHelpPanelPostOnTop and GEHelpPanelAskMentor which were booleans and we want to represent with enumerations now. I think some alternatives are:

1. Migrate the current config options used by CC1.0 and update all the reading occurrences
2. A custom provider that extends WikiPageConfigProvider, overwrites DataProvider::storeValidConfiguration and get to map values in and out. And also a hook “onBeforeValidation” that would turn the real stored configuration into a valid one (PoC 1026617).
3. Make the current code compatible with both data types

Ideas welcome.

In T360472#9765427, @Urbanecm_WMF wrote:

Long-term, I think we should do option 1, but we don't necessarily do it right now. I think an option 4, which would merge option 1 and 2 togehter, would be a reasonable approach as well.

We definitely should migrate the actually stored on-wiki config into the new format. This should be handled as part of T359038: Script to migrate current GrowthExperiments config schemas into new structure (or possibly, a follow-up task to that one, as the description states no data migration should happen). Then, when reading the configuration, we would need to convert the new configuration format into the old one, so that reads would work intact.

This conversion-on-read should happen if and only if CommunityConfiguration's attempt to load valid data from the store was successful. If it was, then the conversion-on-read would need to happen after validation, but before returning the data to the consumer. CommunityConfiguration already provides DataProvider::addAutocomputedProperties(), which is called at the right time, and can be used for this job.

We already make use of this approach for a slightly different need (adding a property which is autocomputed based on other properties), see SuggestedEditsConfigProvider::addAutocomputedProperties().

We might want to rename addAutocomputedProperties() to something else, to reflect it can not only add new properties, but also change existing ones. But it should do the trick.

In T360472#9765427, @Urbanecm_WMF wrote:

We already make use of this approach for a slightly different need (adding a property which is autocomputed based on other properties), see SuggestedEditsConfigProvider::addAutocomputedProperties().

I think this case is different since we're modifying the type of an informed property in the schema from a string enumeration to a boolean. If

We might want to rename addAutocomputedProperties() to something else, to reflect it can not only add new properties, but also change existing ones. But it should do the trick.

If we want to modify existing properties we need to ensure we don't mutate the source since processStoreStatus is called in each config option access.

In T364053#9766441, @Sgs wrote:

In T360472#9765427, @Urbanecm_WMF wrote:

We already make use of this approach for a slightly different need (adding a property which is autocomputed based on other properties), see SuggestedEditsConfigProvider::addAutocomputedProperties().

If we want to modify existing properties we need to ensure we don't mutate the source since processStoreStatus is called in each config option access.

I'm confused. In theory, each call of ::get() should get its own copy of the data, and the manipulation needs to happen on every call. There was the cache pollution bug of course, but that should be now fixed in T364101 (pending QA). So, calling it each time the data is accessed makes sense to me, as the data is actually retrieved each time (although possibly from cache).

Renaming makes sense to me – will happily merge a patch that does that.

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

[mediawiki/extensions/GrowthExperiments@master] Config: support config transforms for some options

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

Change #1026617 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Config: support config transforms for some options

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