Per T128822 and community request Related Pages should now make use of the classic_noboostlinks profile.
Description
Details
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Use 'classic_noboostlinks' search profile | mediawiki/extensions/RelatedArticles | master | +1 -0 |
Related Objects
- Mentioned In
- T128822: Add method for more like api query to not boost pages by popularity
- Mentioned Here
- T135030: [GOAL] Roll related pages from beta on mobile web for most wikis
T141648: Spike: estimate work for T135030 (related pages mobile rollout)
T128822: Add method for more like api query to not boost pages by popularity
Event Timeline
@dr0ptp4kt @Jhernandez Based on positive results that have been published and referred to in all relevant wiki threads, I think this is ready to roll, provided we want to continue with the rollout related pages. I think the next step is to estimate all of the work we think is needed for related pages prior to rollout and an make a call. I created a spike here (T141648) and commented on the epic itself (T135030).
I tried to clean my inbox on my last day of vacation and ended up in phab... ;(
For the sake of our future selves: it's worth considering if the browsing vector work from @ellery could be fit in. To be clear, I think it's okay to make the API URL changes suggested by the Description of this task soon, while considering if the browsing vector work could also be A/B tested down the road on some reasonable timeframe.
CC @Tnegrin, @Fjalapeno
+ @Dbrant @JMinor @pizzzacat, for context in consideration of other sorts of related pages results improvements.
Change 307358 had a related patch set uploaded (by Bmansurov):
Use 'classic_noboostlinks' search profile
This LGTM. The gsrqiprofile query parameter is present for the Related Pages API call. Given the nature of the change, I don't expect this behaviour to vary between browsers – if it does, then we've got bigger problems.