@MMiller_WMF I was wondering if we could get rid of this configuration flag. We used to use it early in the development process to ensure that nothing from Add Link made it to end users. Nowadays, we use the variant system to show add link to some percentage of newly registered accounts. The only reason I can think of to keep it is if we want to retain the ability to have an "emergency shutoff" for Add-Link. If we got rid of GELinkREcommendationsFrontendEnabled and were in a situation where we wanted to temporarily disable the UX, our only option would be to use the main GELinkREcommendationsEnabled config switch, and the practical impact of that is that we would stop refilling the task queue (which doesn't sound like a big problem).
|mediawiki/extensions/GrowthExperiments||master||+1 -23||Remove unnecessary GELinkREcommendationsFrontendEnabled config|
@kostajh -- I think it is probably a good idea to retain an emergency shut-off option for "add a link". If this is the best option for that, then I think we should keep it. Do you see it differently? Like if the situation in German had ended up differently and they wanted to shut it off for all users?
I think there are two use case we would consider the flag for:
- Deploying Add Link to a new wiki: currently users with no variant specified (ie. users who registered before we created the current variant code, about half a year ago) all go to the linkrecommendation group. For new wikis we want a period where the backend is enabled and generating tasks but the frontend is disabled since there are no tasks yet. (Or do we? Maybe we just don't care about the task type showing up almost empty, since it will only be visible to older users.)
- The emergency shutoff. We don't want to disable the backend, because that would mean task generation stops and the task pool decays over time. (It would also mean tasks aren't invalidated when their pages are edited, resulting in lots of "no suggestion found" errors when re-enabling.)
The first could be handled by setting the default variant ($wgGEHomepageDefaultVariant) to control instead of 'linkrecommendation' for those wikis.
The second could be handled by changing the list of allowed variants per-wiki (removing linkrecommendation from VariantHooks::VARIANTS), so essentially we could replace the "frontend enabled" flag with "linkrecommendation variant is not allowed". (This could be an alternative way to handle the first use case as well.) That's hard-coded currently, but it would be easy to add a configuration option for it.