Change #1102796 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/GrowthExperiments@master] PoC(surfacing): request link recommendations while reading

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

The proof of concept was surprisingly easy to get working. Locally, the request takes only about a second, though I did not try it out with very long pages.

Curious what you all think about this!

I think some of the thoughts from T378527#10384905 are relevant for this approach as well. Especially: can we somehow store that we have no suggestions for the combination of revision-id+config-hash+model-hash? That way, we would likely skip a lot of requests to the link-recommendation service coming from this approach here.

Change #1102909 had a related patch set uploaded (by Michael Große; author: Michael Große):

[operations/mediawiki-config@master] beta: enable updating link-suggestions from read-mode

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

Change #1104602 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/GrowthExperiments@master] stats(surfacing): track link recommendation api recommendations

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

Change #1104602 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] stats(surfacing): track link recommendation api recommendations

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

Change #1104624 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/GrowthExperiments@wmf/1.44.0-wmf.6] stats(surfacing): track link recommendation api recommendations

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

Change #1104624 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@wmf/1.44.0-wmf.6] stats(surfacing): track link recommendation api recommendations

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

Mentioned in SAL (#wikimedia-operations) [2024-12-16T15:04:23Z] <ladsgroup@deploy2002> Started scap sync-world: Backport for [[gerrit:1104629|Kick bundlesize out of package.json (T382192 T360590)]], [[gerrit:1104633|fix(surfacing): Show highlights in lists as well (T381841)]], [[gerrit:1104624|stats(surfacing): track link recommendation api recommendations (T378536)]]

Mentioned in SAL (#wikimedia-operations) [2024-12-16T15:09:08Z] <ladsgroup@deploy2002> migr, ladsgroup: Backport for [[gerrit:1104629|Kick bundlesize out of package.json (T382192 T360590)]], [[gerrit:1104633|fix(surfacing): Show highlights in lists as well (T381841)]], [[gerrit:1104624|stats(surfacing): track link recommendation api recommendations (T378536)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-12-16T15:15:54Z] <ladsgroup@deploy2002> Finished scap sync-world: Backport for [[gerrit:1104629|Kick bundlesize out of package.json (T382192 T360590)]], [[gerrit:1104633|fix(surfacing): Show highlights in lists as well (T381841)]], [[gerrit:1104624|stats(surfacing): track link recommendation api recommendations (T378536)]] (duration: 11m 30s)

Change #1102796 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] feat(surfacing): request link recommendations while reading

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

Change #1102909 merged by jenkins-bot:

[operations/mediawiki-config@master] beta: enable updating link-suggestions from read-mode

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

Mentioned in SAL (#wikimedia-operations) [2024-12-17T14:27:58Z] <dcausse@deploy2002> Started scap sync-world: Backport for [[gerrit:1102909|beta: enable updating link-suggestions from read-mode (T378536)]]

Mentioned in SAL (#wikimedia-operations) [2024-12-17T14:34:27Z] <dcausse@deploy2002> migr, dcausse: Backport for [[gerrit:1102909|beta: enable updating link-suggestions from read-mode (T378536)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-12-17T14:46:24Z] <dcausse@deploy2002> Finished scap sync-world: Backport for [[gerrit:1102909|beta: enable updating link-suggestions from read-mode (T378536)]] (duration: 18m 26s)

@Michael This is in Code Review, but it seems all code was already reviewed. Should this be in QA, or is there anything else to upload to finish the first version?

In T378536#10412167, @Urbanecm_WMF wrote:

@Michael This is in Code Review, but it seems all code was already reviewed. Should this be in QA, or is there anything else to upload to finish the first version?

Thanks for pinging me about this. I could have sworn I moved it, but apparently, I didn't. Done now.

QA Note: This is enabled on enwiki beta, but probably very hard to test in practice. First one needs to find an article that is not too long, not too short, not recently edited, not protected and that does not have suggestions. And even then, it all happens in the background and the only noticable difference might be that the suggestion would show up a second later than it would otherwise have.
Once/if we roll it out to production, we will be able to see it in the performance metrics.

In T378536#10413683, @Michael wrote:

QA Note: This is enabled on enwiki beta, but probably very hard to test in practice. First one needs to find an article that is not too long, not too short, not recently edited, not protected and that does not have suggestions. And even then, it all happens in the background and the only noticable difference might be that the suggestion would show up a second later than it would otherwise have.
Once/if we roll it out to production, we will be able to see it in the performance metrics.

Thank you, @Michael! Here are my testing steps on enwiki beta

1. I create a new test user. That new user doesn't get link-recommendation task type enabled
2. Then I try some articles (an example of a query - https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&generator=links&titles=Mavetuna14&prop=cirrusdoc&format=json&cdincludes=weighted_tags) and find articles that do not have references to weighted_tags - maybe my assumptions are wrong here.
3. I found examples of such articles -
4. https://en.m.wikipedia.beta.wmflabs.org/wiki/Mavetuna14
5. https://en.m.wikipedia.beta.wmflabs.org/wiki/Bastet
6. Going to view the articles above (on mobile) - the Console error is dispalyed:

Uncaught (in promise) last_edit_is_a_link_recommendation
loadRecommendations
await in loadRecommendations

Note:

• articles that are returned with hasrecommendation:link do not produce the Console error
• some articles (e.g. Selenium_Echo_mention_test_0.7724579977567869 (the article has one section) produce

Uncaught (in promise) number_of_good_links_too_small__1_

• real short short articles, e.g. Selenium_diff_test_0.975332147718804 won't display an error (the article has only 6 characters)

Questions:
(1) Did I found the right articles for add link recommendations?
(2) Those add link recommendations should be visible in the UI? (I assumed that they are supposed to be highlighted)
(3) Those Console errors - should they be addressed? Or they are a temporary indications of work-in-progress?

@Etonkovidova thank you for catching that!

Background context: these errors indicate that a request for more recommendations was made, but for various good reasons no recommendations can be shown to the user. So, these articles are in principle a good choice.

However, these reasons should not result in an error, as they are purely informational. And also, the informational aspect exists mostly for the benefit of engineers, as those reasons are never intended to be shown to the user. Probably it is best to just remove them from the response.

I'll move it back to Doing to create a fix for this issue.

Change #1108406 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/GrowthExperiments@master] fix(surfacing): prevent console error if no recommendations found

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

Moving back to QA. @Michael, I posted a (non-blocking) thought on the commit. I'd be curious to hear your thoughts about it!

Change #1108406 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] fix(surfacing): prevent console error if no recommendations found

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

In T378536#10431755, @Michael wrote:

@Etonkovidova thank you for catching that!

Background context: these errors indicate that a request for more recommendations was made, but for various good reasons no recommendations can be shown to the user. So, these articles are in principle a good choice.

However, these reasons should not result in an error, as they are purely informational. And also, the informational aspect exists mostly for the benefit of engineers, as those reasons are never intended to be shown to the user. Probably it is best to just remove them from the response.

I'll move it back to Doing to create a fix for this issue.

Thx, @Michael! The console errors are not present anymore.

(1) Artciles for surfacing add link
I've imported some articles - some of them do not get weighted_tags - e.g. https://en.m.wikipedia.beta.wmflabs.org/wiki/Quantum_teleportation. The article only has

"weighted_tags": [
"recommendation.link/__DELETE_GROUPING__"

(see https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&generator=links&titles=Quantum_teleportation&prop=cirrusdoc&format=json&cdincludes=weighted_tags)
Is that article a good candidate to see link recommendations on the fly?

(2) You mentioned that articles for surfacing add link should not be recently editied. The imported articles list the import event in their history - does it count as an edit?

(3) When I override 2% on enwiki beta with ge.utils.setUserVariant('control') does it make a user valid for viewing surface add link suggestions in articles?

I think that API-query is not ideal, because that weight tag seems to not be for Quantum teleportation but for Template:Tech-stub. Which is strange, because pages outside of the main namespace are not supposed to have any kind of recommendation.link tag whatsoever.

I created this query with the two pages mentioned above, and a couple of others that do have weighted tags: https://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=query&format=json&prop=cirrusdoc&titles=Quantum_teleportation%7CTemplate%3ATech-stub%7CDog%7CMammal%7CLion&formatversion=2&cdincludes=weighted_tags

(2) You mentioned that articles for surfacing add link should not be recently editied. The imported articles list the import event in their history - does it count as an edit?

Good question, I'm not fully sure. I think so? (I haven't opened that Quantum_teleportation article in a while, maybe it works now?)

(3) When I override 2% on enwiki beta with ge.utils.setUserVariant('control') does it make a user valid for viewing surface add link suggestions in articles?

Mh, your making a good point. I just encountered this as well, and I think ge.utils.setUserVariant('control') is indeed needed. I think the interaction of those two experiments is indeed not ideal yet, but with putting yourself into the control-group, it should be possible to reliably test it.

Thanks, @Michael! I looked at https://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=query&format=json&prop=cirrusdoc&titles=Quantum_teleportation%7CTemplate%3ATech-stub%7CDog%7CMammal%7CLion&formatversion=2&cdincludes=weighted_tags . The query returns the articles that are already in the link-recommendation task poll. Surfacing link recommendation works for such articles (Dog, Mammal, etc)

As far as I understood the task description, based on

Within this task, we should attempt to create an Add Link suggestion while the user read the article. Once the suggestion is available, the Add Link session can start.

the highlighted links should be provided for articles that are outside the regular link-recommendation pool of tasks that are presented as Add link structured tasks suggestions on Special:Homepage. Now, I think I might've misinterpreted the spec.