Page MenuHomePhabricator

Empty state of Special:CommunityConfiguration/GrowthSuggestedEdits is confusing
Open, HighPublic

Description

When MediaWiki:GrowthExperimentsSuggestedEdits.json does not exist (or is empty) [1], then https://es.wikipedia.beta.wmflabs.org/wiki/Especial:CommunityConfiguration/GrowthSuggestedEdits behaves in a very confusing way. For example, the "Maximum number of links to show per task" looks like this:

image.png (174×2 px, 23 KB)

As an user, I would interpret this as "there is no maximum number of links", expecting GrowthExperiments not to limit the number of links displayed at all. However, in practice, GrowthExperiments recognizes the number is missing (not provided at all), and enhances the configuration with its defaults. As such, when Maximum number of links to show per task" is empty, GrowthExperiments limits the number of links per task to 10.

This comes from GE-specific defaults (in this case, LinkRecommendationTaskType::DEFAULT_SETTINGS), but the behavior is not obvious from the form. It is also probably impossible to know what will happen without reading through our codebase, which is unfair to expect from the admins.

To resolve this, we should add defaults to the Suggested edits schema.

[1] This is the normal case at wikis where CommunityConfiguration is freshly enabled.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Adding some use cases to review for the following:

When MediaWiki:GrowthExperimentsSuggestedEdits.json does not exist (or is empty) [1]
[1] This is the normal case at wikis where CommunityConfiguration is freshly enabled.

Questions:
(1) What would be the initial state of the fields on Special:CommunityConfiguration. Would be the fields pre-filled with the some defaults (visible to users)? Or it'd be up to admins to fill it?
(2) Empty states (the fields without values) are confusing for most cases. Should we make a field-per-field decision on whether to allow empty field or not?
(3) Special:CommunityConfiguration and MediaWiki:GrowthExperimentsSuggestedEdits.json can be moved/deleted (in the Tools menu). To have Special pages to options to be moved/deleted is somewhat unusual. For example, Special:Recentchanges, Special:Watchlist, Special:Contribute do not have these options. Should we disable Move/Delete options for Special:CommunityConfiguration(and submodules) also?

Adding some use cases to review for the following:

Thanks!

Questions:
(1) What would be the initial state of the fields on Special:CommunityConfiguration. Would be the fields pre-filled with the some defaults (visible to users)? Or it'd be up to admins to fill it?

As of now, all fields should have a default, as we currently do not support null/empty values (cf. T365145: Community configuration: Support nullable types). The only possible exception are string types, which could have a default of an empty string.

(2) Empty states (the fields without values) are confusing for most cases. Should we make a field-per-field decision on whether to allow empty field or not?

No value state is not implemented yet. So, something to discuss in T365145 (which is marked as post-MVP).

(3) Special:CommunityConfiguration and MediaWiki:GrowthExperimentsSuggestedEdits.json can be moved/deleted (in the Tools menu). To have Special pages to options to be moved/deleted is somewhat unusual. For example, Special:Recentchanges, Special:Watchlist, Special:Contribute do not have these options. Should we disable Move/Delete options for Special:CommunityConfiguration(and submodules) also?

Hmm... Deleting special pages sounds scary. Those were added in T363788: Community Configuration: Edit History, maybe let's continue the conversation there?

This issue should in practice hopefully be somewhat mitigated by T365045: Not possible to set default values for TYPE_OBJECT properties and T365695: SuggestedEditsSchema uses unsupported nested defaults being fully implemented, right?

Beyond that, I wonder if proper copy, both for the help text as well as an example (the default?) for the placeholder could be sufficient? The help-text could explicitly mention the default behavior. Further, I wonder if that and many other fields should be set as required?