Page MenuHomePhabricator

Avoid per-wiki topic configuration GENewcomerTasksOresTopicConfig
Closed, ResolvedPublic3 Estimated Story Points

Description

After tackling T386018 Growth engineers have considered that it does not make much sense to allow to configure topics per-wiki with GENewcomerTasksOresTopicConfig. Because there aren't real use-cases and because in T386018 a validation of topic ids/names against a different topic source in WikimediaMessages is applied. The decision to introduce GENewcomerTasksOresTopicConfig was made in T367576 to facilitate the adoption of CommunityConfiguration in GrowthExperiments. Now that T388227 is merged that's no longer a need.

Acceptance criteria (DRAFT: pending questions)

  • Remove GENewcomerTasksOresTopicConfig or refactor into something static, eg a constant and update consumers
  • DRAFT: Use the static topics as a fallback when WikimediaMessages is not available

Questions

  • Is the fallback even necessary?
    • How to deal with i18n if WM is not present, display the id?

Event Timeline

After looking a bit into the required changes to keep a Growth internal collection of topics it seems a bit overdue. Historically GE has had validation for the GENewcomerTasksOresTopicConfig config data structure because it was editable by users, but that's no longer the case, so all data shape validation could/should be drop. The only valuable validation that's currently happening is checking the GE configured topic ids have an existing message associated so they can be displayed. This problem is introduced by having two sources of truth, however it is unlikely that Growth supports an extra ORES topic that wouldn't make sense to add to the ArticleTopicRegistry in WikimediaMessages. For that reason, I'm leaning towards the removal of GENewcomerTasksOresTopicConfig instead of keeping a fallback which would be unable to display the topic translations (because those depend on WM). What do you think @Michael?

For me, using a static list of topics in GrowthExperiments as the primary source of truth makes sense in the opposite direction: Someone might add topics, or even entire topic groups, to WikimediaMessages that we do not want in Special:Homepage.

Per 1:1 discussion, we'd keep a Growth internal collection to act as an allow list over WM topic list to keep control over the topics displayed in the homepage.

KStoller-WMF set the point value for this task to 3.

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

[mediawiki/extensions/GrowthExperiments@master] refactor: remove GENewcomerTasksOresTopicConfig in favor of a static collection

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

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

[mediawiki/extensions/GrowthExperiments@master] ITopicRegistry: better method naming

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

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

[mediawiki/extensions/GrowthExperiments@master] [WIP] cleanup(GENewcomerTasksTopicType): sunset topic types

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

Change #1132646 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] refactor: remove GENewcomerTasksOresTopicConfig in favor of a static collection

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

Change #1138315 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] cleanup(GENewcomerTasksTopicType): sunset topic types

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

Change #1134685 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] ITopicRegistry: better method naming

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

Moving to test in production since the main change is already there for weeks and the renaming change shouldn't be problematic.