In T421328#11766590, @DLynch wrote:

Should we manually sync-up the check's config with the growth suggestion's?

@DLynch: could you please add the current state of how Growth has "Add a link" configured and call out which (if any) configurations would require we make adjustments to Edit Check's configuration system to "express"?

This is specifically about "Add a link (structured task)", not "add links between articles".

The configuration, mapped to editcheck terms, is:

{
	"suggestedLink": {
		"lacksTemplate": ["No newcomer task"],
		"notInCategory": ["Candidates for speedy deletion", "Articles for deletion"],
		"ignoreSections": ["", "notes", "notes and references", "references", "sources", "external links", "weblinks", "see also", "further reading", "bibliography", "publications", "works"],
		"predictionThreshold": 0.6
	}
}

What's not supported is:

• Weight of underlinked articles; I'm not actually sure what this applies to -- it doesn't seem to map to any of the API parameters, so I think it might be a configuration for how likely it is to actually show up on the user homepage?
• Maximum number of links to show per task; we don't have any limits by check-type currently.
• Stop suggesting "Add a link" tasks based on newcomers' total edits; suggestions don't currently respect account-based limits, so although we could absolutely add maximumEditcount: 150 to the config it wouldn't have any effect. It's also probably a bit of a different case, since suggestions when you're actually viewing a page and ones where they're being pushed to you somewhere else probably want completely different logic applied

That's specifically enwiki's configuration. Other wikis will have different localized template/category/section exclusions, and would need to be configured per-wiki.

In T421968#11795051, @DLynch wrote:

This is specifically about "Add a link (structured task)", not "add links between articles".

[...]

What's not supported is:

• Weight of underlinked articles; I'm not actually sure what this applies to -- it doesn't seem to map to any of the API parameters, so I think it might be a configuration for how likely it is to actually show up on the user homepage?

That is used in the search for articles with suggestions to create the feed of tasks on the homepage. It is not relevant for you.

• Maximum number of links to show per task; we don't have any limits by check-type currently.

The side effect of that was that we would only show the best quality of suggestions up to the limit. So if you show all the suggestions, you may wish to consider a higher quality limit.

• Stop suggesting "Add a link" tasks based on newcomers' total edits; suggestions don't currently respect account-based limits, so although we could absolutely add maximumEditcount: 150 to the config it wouldn't have any effect. It's also probably a bit of a different case, since suggestions when you're actually viewing a page and ones where they're being pushed to you somewhere else probably want completely different logic applied

This is probably fine. That came from a community request, because most link additions are only mildly useful and the wikis want newcomers to move on to more meaningful tasks. T390079 has more context and discussions, including the community. I think enwiki, and especially dewiki have set this. (dewiki to 5)

Maximum number of links to show per task

Should we do this one? @ppelberg
-> this would be a 1 or 2 as estimate.

Other options (that are easily implemented with the config) -> those options are 0 to 1 as estimates

• restrict it to higher threshold
• only suggestions in the lead section

Other question to figure out:

• should we migrate the existing growth community configuration to our edit check configuration?

The tendencies of the Add-a-Link model to suggest overlinks and to suggest linking over partial terms have been points of community concern, and this could scale if deployed in Suggestion Mode. T415623 and T405185 respectively could help address these issues.

Per offline discussion, the Editing Team is aligned with the Growth Team in thinking that, at least to start, it is important that the configuration values governing how "Add a link" gets presented in the newcomer homepage (MediaWiki:GrowthExperimentsSuggestedEdits.json) be mirrored within the configuration values governing how the "Add a link" suggestion gets presented within Suggestion Mode.

To enable the above, the Editing Team will implement a new API that will:

1. Listen for changes to MediaWiki:GrowthExperimentsSuggestedEdits.json
2. Update to MediaWiki:Editcheck-config.json to reflect relevant changes in MediaWiki:GrowthExperimentsSuggestedEdits.json

The work to implement this API will happen in TICKET and the deployment of "Add a link" in Suggestion Mode as a default Suggestion will be blocked on its completion.

Two notes:

1. Emphasis on "relevant" above b/c there may be configuration values within MediaWiki:GrowthExperimentsSuggestedEdits.json that we may deem unnecessary to implement in MediaWiki:Editcheck-config.json
2. The API TICKET will introduce will be relevant now and in a potential future wherein EditCheck-config.json is migrated to the Community Configuration extension (T372927)

In T421968#11800583, @VPuffetMichel wrote:

Maximum number of links to show per task

Should we do this one? @ppelberg
-> this would be a 1 or 2 as estimate.

To start, no. Instead, we'll learn if the default threshold 0.6 (I believe) is causing a high number of link suggestions to be shown on a given article.

If/when we come to learn the above is happening, we'll propose that threshold be increased. If that doesn't work, we'll implement the ability to set a hard cap on how many suggestions can be shown within a given article.

Other options (that are easily implemented with the config) -> those options are 0 to 1 as estimates

• restrict it to higher threshold
• only suggestions in the lead section

Other question to figure out:

• should we migrate the existing growth community configuration to our edit check configuration?

Per offline discussion, not yet. Instead, we'll implement an API that enables the two to be kept in sync: T422730

Blocked on what's described in T422730#11871895 being done.