A Link Recommendation Service, primarily for the "Personalized first day" initiatives of the WMF Growth team.
Mentioned in SAL (#wikimedia-operations) [2024-12-02T18:39:14Z] <urbanecm@deploy2002> Finished scap sync-world: Backport for [[gerrit:1099736|ApiQueryLinkRecommendations: Do not use relative protocol URIs (T381277)]] (duration: 10m 35s)
Mentioned in SAL (#wikimedia-operations) [2024-12-02T18:32:11Z] <urbanecm@deploy2002> urbanecm: Backport for [[gerrit:1099736|ApiQueryLinkRecommendations: Do not use relative protocol URIs (T381277)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Mentioned in SAL (#wikimedia-operations) [2024-12-02T18:28:39Z] <urbanecm@deploy2002> Started scap sync-world: Backport for [[gerrit:1099736|ApiQueryLinkRecommendations: Do not use relative protocol URIs (T381277)]]
Oh cool! For some reason, I thought that would only work for path-relative URLs. Thanks @matmarex!
Change #1099714 abandoned by Urbanecm:
[mediawiki/extensions/GrowthExperiments@master] fix(StructuredTask.Surfacing): provide url string valid for new URL
Reason:
went for an alternative solution
For future reference, you can also resolve this kind of problem by passing a second argument to the new URL(…) constructor. If the first argument is a (potentially) relative URL, the second should be an absolute URL, and the relative URL will be resolved in relation to the absolute one, instead of causing an error. It's usually correct to pass location.href, which will match how the browser would resolve the relative URL.
Mentioned in SAL (#wikimedia-operations) [2024-12-02T18:00:48Z] <urbanecm@deploy2002> urbanecm: Backport for [[gerrit:1099736|ApiQueryLinkRecommendations: Do not use relative protocol URIs (T381277)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Mentioned in SAL (#wikimedia-operations) [2024-12-02T17:57:27Z] <urbanecm@deploy2002> Started scap sync-world: Backport for [[gerrit:1099736|ApiQueryLinkRecommendations: Do not use relative protocol URIs (T381277)]]
Mentioned in SAL (#wikimedia-operations) [2024-12-02T17:54:50Z] <urbanecm@deploy2002> urbanecm: Backport for [[gerrit:1099736|ApiQueryLinkRecommendations: Do not use relative protocol URIs (T381277)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Mentioned in SAL (#wikimedia-operations) [2024-12-02T17:50:25Z] <urbanecm@deploy2002> Started scap sync-world: Backport for [[gerrit:1099736|ApiQueryLinkRecommendations: Do not use relative protocol URIs (T381277)]]
Change #1099736 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.44.0-wmf.5] ApiQueryLinkRecommendations: Do not use relative protocol URIs
Change #1099722 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] ApiQueryLinkRecommendations: Do not use relative protocol URIs
Change #1099736 had a related patch set uploaded (by Urbanecm; author: Urbanecm):
[mediawiki/extensions/GrowthExperiments@wmf/1.44.0-wmf.5] ApiQueryLinkRecommendations: Do not use relative protocol URIs
Change #1094498 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] TaskSuggester: make search queries multi topic
Change #1094497 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] instrumentation(NewcomerTasks): remove match_score and topic from events
Thx, @Urbanecm_WMF - I'll monitor more for couple of days the RC filter with newcomers, learners, and experienced users. Last timestamp for a Suggested: add link edit made by non-newcomer - Nov 26, 17:54.
Where in that GrowthMaintenance class would you call StatsFactory->flush() and how would you call that from our maintenance scripts?
Change #1098492 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):
[mediawiki/extensions/GrowthExperiments@master] refactor(SearchStrategy): extract query build methods to functions
grafana Dangling DB records chart shows sharp decrease around Nov18/2024 (and no records at all for the last week).
In principle, this should be ready to be worked on, but I would feel better doing it if we actually had the related metrics. Currently, we don't due to T380635/T380609: Maintenance scripts do not emit StatsLib metrics.
Mentioned in SAL (#wikimedia-operations) [2024-11-26T16:40:51Z] <urbanecm> mwscript-k8s -f userOptions.php -- --wiki=enwiki --old=control --delete 'growthexperiments-homepage-variant' # T379146, T377631
Change #1093900 abandoned by Sergio Gimeno:
[mediawiki/extensions/GrowthExperiments@master] instrumentation(NewcomerTaskLogger): remove match_score and topic from events
Reason:
Squashed in Ic366fb6dee56d89c56c16c528f082aae06fff23e
Checked on enwiki wmf.4 - RecentChanges show edits tagged with Suggested:add links made by non-new accounts.
Deployed. I also enabled Add Link via Community Configuration, to ensure it is actually visible to users (the 2% we enabled for). Moving to QA!
Mentioned in SAL (#wikimedia-operations) [2024-11-25T19:36:24Z] <urbanecm@deploy2002> Finished scap sync-world: Backport for [[gerrit:1095126|[Growth] enwiki: Deploy Add Link to 2% of new users (T377631)]] (duration: 11m 59s)
Mentioned in SAL (#wikimedia-operations) [2024-11-25T19:28:37Z] <urbanecm@deploy2002> urbanecm: Backport for [[gerrit:1095126|[Growth] enwiki: Deploy Add Link to 2% of new users (T377631)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Mentioned in SAL (#wikimedia-operations) [2024-11-25T19:24:24Z] <urbanecm@deploy2002> Started scap sync-world: Backport for [[gerrit:1095126|[Growth] enwiki: Deploy Add Link to 2% of new users (T377631)]]
Change #1095126 merged by jenkins-bot:
[operations/mediawiki-config@master] [Growth] enwiki: Deploy Add Link to 2% of new users