There are two possible solutions here, I'll call them option 1 and option 2.

Option 1: Move all MediaWiki configuration variables elsewhere (out of https://es.wikipedia.beta.wmflabs.org/wiki/Especial:CommunityConfiguration/GrowthSuggestedEdits), and leave only suggested edits task type in https://es.wikipedia.beta.wmflabs.org/wiki/Especial:CommunityConfiguration/GrowthSuggestedEdits. This would mean moving them to
https://es.wikipedia.beta.wmflabs.org/wiki/Especial:CommunityConfiguration/GrowthHomepage, or possibly a fully new provider/feature.

Option 2: Create a fictitious provider in GrowthExperiments, which would present as a mw-config provider, and load data from GrowthSuggestedEdits. That way, the data could be edited in a single form, but would be internally presented as two separate providers.

After a discussion with @Sgs, option 1 is more appealing to me, for a couple of reasons:

• Option 2 is hacking around CommunityConfiguration, and trying to make it behave in a way it was not designed for. It will likely work, but it will be harder to maintain in the long run, increasing our level of Technical-Debt.
• Conceptually speaking, none of the proposed variables is really related to suggested edits task types (which is the main purpose of https://es.wikipedia.beta.wmflabs.org/wiki/Especial:CommunityConfiguration/GrowthSuggestedEdits). The list of infoboxes is currently only used in Suggested edits, but in reality, it makes Search aware of what templates are infoboxes and what templates are not, making it possible for anyone (not just Suggested edits, or not just Growth) to use this information. Similarly, while Levelling up highlights Suggested edits, it is really a feature of its own, rather than a part of Suggested edits (in other words: Suggested edits can work just fine without Levelling up; they just might end up being used by fewer people).

For those reasons, @Sgs and me suggest to do the following:

Solution proposal

Within this task, we need to:

• move "Infobox templates" configuration from https://es.wikipedia.beta.wmflabs.org/wiki/Especial:CommunityConfiguration/GrowthSuggestedEdits to https://es.wikipedia.beta.wmflabs.org/wiki/Especial:CommunityConfiguration/GrowthHomepage, and
• rename "Newcomer Homepage" feature to "Other Growth features" (would affect the dashboard at https://es.wikipedia.beta.wmflabs.org/wiki/Especial:CommunityConfiguration)

The renaming is suggested in order to make the decision about "what configuration option is where" more obvious. As of now, all config options we have in Community configuration relate to the Homepage (more or less): Suggested edits are a part of Homepage (they cannot be accessed without using the Homepage first); Help panel links are presented not only in the Help panel, but also in the Homepage; Mentorship module is primarily advertised on the Homepage; etc. As a result, the "Newcomer Homepage" feature plays the role of a catch all already, and the suggested renaming makes that more obvious.

Once this is done, we would then be able to work on T365612: Growth features: Add Levelling up related configuration and add Levelling up to CommunityConfiguration.

To me there are several other options we could consider:

• Option 3: Change GEInfoboxTemplates to be treated as data instead of a config variable inside of GE, when using CC is enabled.
• Option 4: Split up and integrate GEInfoboxTemplates into the tasks that actually make use of it. Unless that would duplicate the "Articles containing templates defined here will not be shown to users as tasks for this task type"-field? (I'm not sure I fully understand what the difference is, to be honest.)
• Option 5: Treat all of SuggestedEdits as config. While it would be pretty complex config, that is still not unheard of, and it is still pretty much distinct in kind from just a list of mentors where experienced editors self-enroll.

My main concern with the chosen Option 1 from above is that it would seem to me to be a significant reduction in the understandability of our configuration if one option to affect SuggestedEdits is buried in a different form for, from the admin's perspective, no good reason.

However, I can see that Option 1 is likely the quickest to implement. And with good copy, we should be able to somewhat mitigate the impact of this structured tasks configuration being spread out over multiple forms.

That all being said, I agree that the leveling up configuration probably does not belong on the suggested edits form. These notifications are, to my (lacking!) understanding, merely a way to surface these tasks, they don't affect the tasks themselves the way GEInfoboxTemplates does.

In T365606#9829520, @Michael wrote:

To me there are several other options we could consider:

• Option 3: Change GEInfoboxTemplates to be treated as data instead of a config variable inside of GE, when using CC is enabled.

That would work, it would also be pretty concise since it seems it is only used in HomepageHooks.php#1467 aside from SpecialEditGrowthConfig

• Option 4: Split up and integrate GEInfoboxTemplates into the tasks that actually make use of it. Unless that would duplicate the "Articles containing templates defined here will not be shown to users as tasks for this task type"-field? (I'm not sure I fully understand what the difference is, to be honest.)

This option also implies option 3 but it requires deeper changes. Infobox templates are only used for image tasks afaik, they could serve other purposes but they don't and haven't in a while. So it maybe a good idea for the future.

• Option 5: Treat all of SuggestedEdits as config. While it would be pretty complex config, that is still not unheard of, and it is still pretty much distinct in kind from just a list of mentors where experienced editors self-enroll.

I would not push unnecessary options to "server config", maybe we should have some "guideline" around this.

My main concern with the chosen Option 1 from above is that it would seem to me to be a significant reduction in the understandability of our configuration if one option to affect SuggestedEdits is buried in a different form for, from the admin's perspective, no good reason.

I agree with this arguments, that's why I'm leaning towards option (3) over (1). However I feel classifying config options per-feature is to strict in the sense that it locks the config option to a single usage while this might not always be true. While the infobox template case seems indeed specific to the suggested edits feature and the "image_recommendation" newcomer task, maybe we should come up with a guideline for this. eg: Config options used by different features should have its own provider.

However, I can see that Option 1 is likely the quickest to implement. And with good copy, we should be able to somewhat mitigate the impact of this structured tasks configuration being spread out over multiple forms.

I'm leaning towards option (3) over (1) unless @Urbanecm_WMF has strong concerns against.

That all being said, I agree that the leveling up configuration probably does not belong on the suggested edits form. These notifications are, to my (lacking!) understanding, merely a way to surface these tasks, they don't affect the tasks themselves the way GEInfoboxTemplates does.

Indeed. From a GrowthExperiments product perspective I think the taxonomy of Leveling up is: GrowthExperiments > Positive reinforcement > Leveling up. Changing the title removing "homepage" makes sense to not lock us. I think last @KStoller-WMF proposal is “Newcomer onboarding”.

I agree that option 3 is the way to go – given the self-containedness of the usage, it makes sense to go for that option. Thanks @Michael for listing the options!

In T365606#9834563, @Sgs wrote:

That all being said, I agree that the leveling up configuration probably does not belong on the suggested edits form. These notifications are, to my (lacking!) understanding, merely a way to surface these tasks, they don't affect the tasks themselves the way GEInfoboxTemplates does.

Indeed. From a GrowthExperiments product perspective I think the taxonomy of Leveling up is: GrowthExperiments > Positive reinforcement > Leveling up. Changing the title removing "homepage" makes sense to not lock us. I think last @KStoller-WMF proposal is “Newcomer onboarding”.

+1 to that interpretation.

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

[mediawiki/extensions/GrowthExperiments@master] Config: move GEInfoboxTemplates to newcomer schema

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

Change #1036635 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Config: load infobox templates from newcomer tasks loader

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

✅ (1) the current implementation includes Infobox templates for image suggestions tasks and it matches the production cswiki Special:EditGrowthConfig
figma mockup doesn't reflect the implementation,

The implemented UI:

I read the comments and it seems that the implemented UI correctly reflects the decision that was made.

✅ the per wiki configuration settings are preserved (2) Would be the current lists of infoboxes templates (and other templates that wikis have on Special:editGrowthConfig) be copied/migrated to Special:CommunityConfiguration/GrowthSuggestedEdits?

In T365606#9866005, @Etonkovidova wrote:

[...]
(2) Would be the current lists of infoboxes templates (and other templates that wikis have on Special:editGrowthConfig) be copied/migrated to Special:CommunityConfiguration/GrowthSuggestedEdits?

It should – the maintenance script we run during deployment should do that. If that is not the case, we should definitely take a look at why.