The default threshold for generating a link suggestion is 0.5. We can consider raising this to 0.6 or 0.7. That would have the following effects:
- The suggestions presented to the end user will have a higher likelihood of being good quality links, and will be less likely to be reverted.
- Indirectly, that might impact T301096: Add a link: prioritize suggestions of underlinked articles, because theoretically the higher quality links will be less likely to be unlinked phrases in heavily-linked articles.
- For each article, the link recommendation service will identify fewer phrases as link suggestions (e.g. instead of 5 phrases, it might find 1 or 2).
- It's hard to say how many fewer suggestions we would get per article. If we wanted to find out, we could write a fairly straightforward script to iterate over cached link recommendations in the database and gather statistics about the confidence score for each suggestion.
- Because we have a minimum threshold of two suggestions for an article to be considered as a candidate link recommendation task, there will be fewer articles in the task queue, and/or it will take longer to repopulate the task queue for each wiki.
- Task pool sizes seem to stay fairly constant (https://grafana.wikimedia.org/d/vGq7hbnMz/special-homepage-and-suggested-edits?orgId=1&from=now-7d&to=now), but smaller wikis may be more impacted by this change. It's hard to say in advance. On medium-sized and larger wikis, you'd be unlikely to have a scenario where there aren't enough tasks in the queue.
- The threshold for link suggestions is set at a higher value: 0.6
- Run revalidateLinkRecommendations.php on the affected wikis
- The patches have been code reviewed and merged
- The task passes its acceptance criteria
- There are existing and passing unit/integration tests
- Tests for every involved patch should pass
- Coverage for every involved project should have improved or stayed the same
Design & QA
- If the task is UX/Design related: it must be reviewed and approved by the UX/Design team
- Must be reviewed and approved by Quality Assurance.
- Related and updated documentation done where necessary
- Internal technical changes: internal repository documentation must be updated (README.md, JSDoc, PHPDoc)
- Infrastructure technical changes: technical changes that reflect on environment, infrastructure, endpoints or any other area of interest for technical contributors should be reflected on Extension:GrowthExperiments or Extension:GrowthExperiments/Technical documentation pages.
- Announce it where needed (mostly in the Growth Newsletter)