As a part of this, we should probably update NewcomerTasksUserOptionsLookup and TaskTypesAbFilter to handle the situation when expected task types don't exist, and provide some sort of fallback mechanism, e.g. if link is not available use copyedit. That makes it possible to disable a task type just by removing it from the task type config (sort of possible currently but with some minor bugs). It would also fix T294486: GrowthExperiments SuggestedEdits module gets confused when selected task types don't exist.

@Tgr -- thanks for creating this task. I remember when we first discussed community configuration for "add an image", @kostajh recommended that we save it for a future iteration. Are you saying that this particular configuration would be important enough to include in the first iteration? If so, is it also easy to include others along with it?

These are configurations I could imagine including:

• The number of tasks for the quality gate (default at 25).
• The minimum number of characters for caption validation (default at 5).
• Whether to include BLPs in the feed (default is yes).

Can we have a way to know rapidly if a community turned Add an image off?

In T294518#7473338, @MMiller_WMF wrote:

Are you saying that this particular configuration would be important enough to include in the first iteration?

It's a product decision, but I think it would be good to have a "kill switch" available to the wiki community in case Add Image results in bad edits or turns out to be buggy in some major way (e.g. breaks the homepage) given that most of the WMF will be on a 1.5-week holiday not too long after Add Image is launched.

If so, is it also easy to include others along with it?

It's orthogonal, in that doing one won't make the other easier. Although that depends on how we implement the kill switch. My thinking was:

• fix the small issues we currently have when a task type is removed (T294486: GrowthExperiments SuggestedEdits module gets confused when selected task types don't exist):
  • make sure everything that uses $wgGENewcomerTasksLinkRecommendationsEnabled / $wgGENewcomerTasksImageRecommendationsEnabled takes into account whether the relevant task type exists (except Special:EditGrowthConfig I guess)
  • update NewcomerTasksUserOptionsLookup and TaskTypesAbFilter to handle the situation when expected task types don't exist, and provide some sort of fallback mechanism, e.g. if link is not available use copyedit
• fix Special:EditGrowthConfig to not re-add task types which aren't there

Admins can then just remove the task type from MediaWiki:NewcomerTasks.json to disable it. It wouldn't have a nice Special:EditGrowthConfig equivalent but I think that's okay.

Another approach would be to make it possible to have different form fields for different task types, and introduce a "disabled" field that admins can check via Special:EditGrowthConfig. That's a more complicated change, but would make adding other fields (quality gate limits etc) very easy.

In T294518#7475478, @Trizek-WMF wrote:

Can we have a way to know rapidly if a community turned Add an image off?

Someone can watchlist the relevant config pages; I assume they don't change much. Or maybe @Urbanecm_WMF's community configuration dashboard has some magic that could be used here.

Okay, @Tgr, since the different community configs are orthogonal, then let's only add this one. I think it will be good ot have a kill switch. I'm putting this in Ready for Development. I'll task the other community configs separately.

With respect to knowing when a community turns the feature off, I know @Urbanecm_WMF has a regular script to check on the usage of community configuration.

Also, @Tgr, I wonder if it will be important to decide what happens to people who only have this task selected in their difficulty filters, once community configuration flips it off. That group would include the whole treatment group per T294737: Add an image: experiment.

Yeah, that's what I meant with fallback mechanism. We'll probably want to hardcode something like "if there are no task types left after filtering out the disabled ones, just add first (easiest) one" for the default task types. And if a user is left with no valid task types in their preferences, use the defaults instead.

In T294518#7476471, @Tgr wrote:

In T294518#7475478, @Trizek-WMF wrote:

Can we have a way to know rapidly if a community turned Add an image off?

Someone can watchlist the relevant config pages; I assume they don't change much. Or maybe @Urbanecm_WMF's community configuration dashboard has some magic that could be used here.

The only thing I have is https://martin-urbanec.toolforge.org/growth-reports/community_configuration_usage/, which monitors community configuration usage across all the wikis. It does not, however, check the actual diff made, mainly because just looking at the metadata available in replicas is significantly easier.

If we want a rapid way of knowing, we can build something that hooks to streams.wikimedia.org and pings us (via mail?) if something happens to image recommendation. Watchlisting the pages and reviewing changes manually might be "cheaper" though; noting it here just for completeness.

In T294518#7476606, @Urbanecm_WMF wrote:

If we want a rapid way of knowing, we can build something that hooks to streams.wikimedia.org and pings us (via mail?) if something happens to image recommendation. Watchlisting the pages and reviewing changes manually might be "cheaper" though; noting it here just for completeness.

From a user perspective, using Stream would be more efficient than relying on Watchlists. If you don't visit your watchlist once, it is over. And if the person who takes care of the watchlist if not around, we can miss some events.

From a developer perspective, watchlists already exist :)

Loosely related but we should probably also make sure the 800 limit hardcoded into TemplateCollectionFeature is also enforced on the community config side.

Change 738294 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] Add Image: Validate GEInfoboxTemplates size

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

Change 738606 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] Suggested edits: Allow disabling task types via community config

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

Change 738607 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] [WIP] Suggested edits: Allow disabling task types via community config #2

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

@kostajh qualityGateIds does not seem useful right now - maxTasksPerDay having / not having been set would presumably enable/disable that gate, and the mobile gate should not be community-configurable. minimumCaptionCharacterLength is part of T294887: Add an image: community configurations (probably the only complicated part of it, in fact, as it's only valid for one task type). maxTasksPerDay seems simple enough.

In T294518#7502906, @Tgr wrote:

@kostajh qualityGateIds does not seem useful right now - maxTasksPerDay having / not having been set would presumably enable/disable that gate, and the mobile gate should not be community-configurable. minimumCaptionCharacterLength is part of T294887: Add an image: community configurations (probably the only complicated part of it, in fact, as it's only valid for one task type). maxTasksPerDay seems simple enough.

OK, fair enough. SpecialEditGrowthConfig needs to know about the fields, though, otherwise they get erased when the form is submitted.

Change 738606 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Suggested edits: Allow disabling task types via community config

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

Change 738607 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Suggested edits: Allow disabling task types via community config #2

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

In T294518#7476562, @Tgr wrote:

Yeah, that's what I meant with fallback mechanism. We'll probably want to hardcode something like "if there are no task types left after filtering out the disabled ones, just add first (easiest) one" for the default task types. And if a user is left with no valid task types in their preferences, use the defaults instead.

@Tgr -- okay, I think having a fallback mechanism is a good idea. How about "if a user has no valid task types, set them back up with the defaults that new users get". But would that end up being circular in the sense that the defaults that some new users get is "add an image"? Would we have a sense of the "status quo default"?

In T294518#7502906, @Tgr wrote:

@kostajh qualityGateIds does not seem useful right now - maxTasksPerDay having / not having been set would presumably enable/disable that gate, and the mobile gate should not be community-configurable. minimumCaptionCharacterLength is part of T294887: Add an image: community configurations (probably the only complicated part of it, in fact, as it's only valid for one task type). maxTasksPerDay seems simple enough.

@Tgr -- which ones do you plan to implement as part of this task? When you say, I can make sure that this task and T294887: Add an image: community configurations each have the right ones listed without overlap.

In T294518#7477243, @Trizek-WMF wrote:

In T294518#7476606, @Urbanecm_WMF wrote:

If we want a rapid way of knowing, we can build something that hooks to streams.wikimedia.org and pings us (via mail?) if something happens to image recommendation. Watchlisting the pages and reviewing changes manually might be "cheaper" though; noting it here just for completeness.

From a user perspective, using Stream would be more efficient than relying on Watchlists. If you don't visit your watchlist once, it is over. And if the person who takes care of the watchlist if not around, we can miss some events.

@Urbanecm_WMF @Trizek-WMF -- rather than build something here, maybe we should start out with just asking the ambassadors to keep an eye on this via watchlist. @Urbanecm_WMF, could you create a task for building something to let us know? And we can decide whether to prioritize it later?

In T294518#7491194, @Tgr wrote:

Loosely related but we should probably also make sure the 800 limit hardcoded into TemplateCollectionFeature is also enforced on the community config side.

@Tgr -- is this something that we'll do as part of this task, or should we file a separate task? If so, could you please file it?

In T294518#7502956, @kostajh wrote:

SpecialEditGrowthConfig needs to know about the fields, though, otherwise they get erased when the form is submitted.

IMO SpecialEditGrowthConfig should not touch tasktype fields it doesn't know about, and that seems like an easy change.

Change 738294 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add Image: Validate GEInfoboxTemplates size

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

@Tgr -- could you please note on this task which configurations you do and don't end up implementing for Iteration 1?

In T294518#7511617, @MMiller_WMF wrote:

@Tgr -- could you please note on this task which configurations you do and don't end up implementing for Iteration 1?

I think what's fairly easy to do is:

• fix Special:EditGrowthConfig to not remove tasktype properties it doesn't know about
• add maxTasksPerDay and minimumCaptionCharacterLength tastype properties (ie. adding them in JSON should work, even if the edit form doesn't display them) - also qualityGateIds if wanted although I'd rather go for one widget per gate type instead
• add a form widget (per task type) for maxTasksPerDay

What would be left out is

• coming up with some mechanism for different task types having different form widgets
• adding a form widget for minimumCaptionCharacterLength to the image-recommendation task type

I assume the mobile-only quality gate should not be community-configurable in any way.

@Tgr -- okay, I think having a fallback mechanism is a good idea. How about "if a user has no valid task types, set them back up with the defaults that new users get". But would that end up being circular in the sense that the defaults that some new users get is "add an image"? Would we have a sense of the "status quo default"?

Yeah, we could probably use the "default default". Or just take all tasks and use the two easiest.
This is the same problem we face when the user reaches the quality gate so I imagine we want to apply the same logic there?

Loosely related but we should probably also make sure the 800 limit hardcoded into TemplateCollectionFeature is also enforced on the community config side.

@Tgr -- is this something that we'll do as part of this task, or should we file a separate task? If so, could you please file it?

This was done recently.

Change 740777 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@wmf/1.38.0-wmf.9] Add Image: Validate GEInfoboxTemplates size

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

Change 740777 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@wmf/1.38.0-wmf.9] Add Image: Validate GEInfoboxTemplates size

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

Mentioned in SAL (#wikimedia-operations) [2021-11-23T21:47:15Z] <tgr@deploy1002> Synchronized php-1.38.0-wmf.9/extensions/GrowthExperiments: Backport: [[gerrit:740777|Add Image: Validate GEInfoboxTemplates size (T294518)]] (duration: 00m 56s)

We should probably indicate when a task type is disabled via a different mechanism. Most of the time that will result in it not showing up at all, but with $wgGELinkRecommendationsFrontendEnabled that isn't the case, and it will be confusing e.g. for dewiki admins to see the feature shown as enabled.

Change 741978 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] SpecialEditGrowthConfig: Do not override unexpected data

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

Change 741979 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] Add Image: Community config for quality gate + caption length

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

Change 741993 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] Community configuration: Handle disabled task types

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

With the patches:

• any task type can be disabled by wiki admins

• if a task type has been disabled via central (PHP) configuration, it won't show up on the special page
• if link recommendations are partially disabled ($wgGELinkRecommendationsFrontendEnabled), a notice is shown

Change 741978 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] SpecialEditGrowthConfig: Do not override unexpected data

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

Change 741979 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add Image: Community config for quality gate + caption length

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

Change 741993 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Community configuration: Handle disabled task types

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

Removed the part of the task description that's duplicated in T294887: Add an image: community configurations, and moved that into the sprint. Other than that, everything is merged here.

@Tgr - for your review. It could be only betalabs-specific issues.

Tested in betalabs

• I disabled Copyedit and Add image tasks types via MediaWiki:NewcomerTasks.json
• Special:EditGrowthConfig correctly shows that the task types are disabled, e.g.:

• a user logs in and sees that there is

(1) no indications that some tasks have been disabled. Should users be informed/warned in some way? Not seeing previous task type filters might be disruptive and confusing. Probably, a simple text such as "Available task types"?
(2) The task types filters (after disabling some tasks on Special:EditGrowthConfig) would not display any pre-selected task types. A user would be facing with un-selected tasks types filters.

That would result in the following:
(3) The first SE card would be loaded. The right hand navigation (the arrows) would look active, but if a user clicks on the navigation arrow, the incorrect counter and the warning would be displayed:

In T294518#7618433, @Etonkovidova wrote:

Should users be informed/warned in some way?

Seems more confusing than useful. Primarily disabling will be used if the community does not want that type of task on their wiki.

The task types filters (after disabling some tasks on Special:EditGrowthConfig) would not gave pre-selected task types. A user would be facing with un-selected tasks types filters.

That's a variant of T294486: GrowthExperiments SuggestedEdits module gets confused when selected task types don't exist. It's not strictly related to to this task (the same would happen if the default tasks get disabled in an other way, e.g. there are no applicable templates). We should fix it; I'm not sure how we should fix it though.