Purpose of the manual

The current manual has three CC-facing steps:

1. Pre-create a boilerplate configuration (by saving { "type": "link-recommendation", "group": "easy" } under link-recommendation if the CC page does not exist)
2. Generate excluded sections using a pre-computed wiki_sections.jsonl (T306792#7897336, F35092312)
3. Save that list of excluded sections onto the config page

Once this is completed, the manual sees to first set wgGENewcomerTasksLinkRecommendationsEnabled to true, followed by wgGELinkRecommendationsFrontendEnabled. This is still accurate.

Differences

• Using a CC1.0 script (extensions/GrowthExperiments/maintenance/changeWikiConfig.php no longer exists`)
  • today's equivalent: CommunityConfiguration:ChangeWikiConfig
  • the page title is no longer an identifier; instead, the provider name should be used (GrowthSuggestedEdits here)
  • --json parameter is not recognised; all values are instead parsed as JSON, so this just needs to be excluded
  • --create-only parameter is not recognised; it is not possible to run ChangeWikiConfig so that it only does a first edit; I believe this is not necessary, see below
• link-recommendation was replaced by link_recommendation instead

Open Questions

Really only one: How important are excluded sections for us?

Option (A): Keeping them

We have a long-standing task (T345562: Generate excludedSections list for wikis missing in wiki_sections.jsonl) about generating the excluded sections for all wikis. The main issue is that the section alingment data we used for this is from 2022, and many wikis were created since then. Research project documentation exists as well as the source code, so we should be in principle able to repeat that work. However, it would be working in not-so-familiar area for us, likely resulting in more time spent.

Option (B): No longer provisioning excluded sections automatically

The only alternative besides this is to remove excluded sections pre-generation from the docs, since it is not going to be successful for the vast majority of new deployments (=they are going to happen on new-ish Wikipedias).

This is probably a question for @KStoller-WMF. Unfortunately, as I'm not very familiar with the section-alignment code, I'm not sure how easy it would be to run. If we allocate an engineer-sprint to find that out, we might know more.

If we didn't have so many competing high priorities, Option A would be ideal, but I personally think our engineering time would be better spent tackling other problems and so I suggest moving forward with Option B.

Option (B): No longer provisioning excluded sections automatically

Communities have the ability to adjust excluded sections via Community Configuration, and edit tags will point experienced editors to a MW page that explains:

Newcomer tasks are configurable by communities by visiting Special:CommunityConfiguration locally.

It's not perfect, but we are providing communities with the tools to improve the task, and I think that's good enough for now.

I updated most of the documentation based on @KStoller-WMF's answer (thank you!). I still need to update the command to prepopulate sections (mostly to keep archives happy), and then this task can be considered resolved.

And adjusted the comment, explicitly framing excluded sections as optional. I'd call that simplified enough. Moving to Code Review, mostly to get a perspective from @Michael and/or @Sgs (or other engineers, if they have any).

In T410457#11553424, @Urbanecm_WMF wrote:

And adjusted the comment, explicitly framing excluded sections as optional. I'd call that simplified enough. Moving to Code Review, mostly to get a perspective from @Michael and/or @Sgs (or other engineers, if they have any).

I can't fully verify the script snippet because I'm not a deployer and so not familiar with the k8s-related details, but the rest of that sections reads very straightforward and matches my understanding about what needs doing. Thank you!

IIRC, that script should be runnable with restricted permissions (which you have)? In any case, thank you for the review!