Page MenuHomePhabricator

Summarize what it will take to separate UI and infrastructure for ORES Extension
Closed, ResolvedPublic

Description

In the interest of keeping Scoring and Collab teams' work streams independent, and for code hygiene in either case, we'd like to decompose Extension:ORES into a UI module, and an infrastructure module responsible for maintaining the DB-local score cache.

We'll keep a single code base, but split by directory and namespace each module.

A new, boolean configuration variable will allow us to suppress the UI so it can be rolled out independently of the backend.

We should keep code changes to a dull roar for this first phase, since the primary goal here is to decouple our work streams.

Details

Related Gerrit Patches:
mediawiki/extensions/ORES : masterAllow filter UI to be turned off

Event Timeline

Halfak created this task.Jun 14 2017, 6:53 PM
Restricted Application added a project: Scoring-platform-team. · View Herald TranscriptJun 14 2017, 6:53 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Halfak renamed this task from Summarize what it will take to separate product and platform ORES to Summarize what it will take to separate product and platform for ORES Extension.Jun 14 2017, 6:54 PM

Change 359364 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/ORES@master] Allow structured filters integration to be turned off

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

With this patch, the Scoring team will be able to deploy the ORES review tool ("classic ORES interface") to new wikis without also deploying the New Filters for Edit Review ("RCFilters") integration at the same time, by setting $wgOresEnableStructuredFilters to false on that wiki.

Yes, that's perfect! My current preference is that we generalize the config to also control "classic" ORES, if you agree? The main use case I'm imagining is that we're deploying a new ORES model but want to schedule the UI change independently. I'm considering the UI as composed of three parts: new ORES RC filters, Special:Contribution simple ORES filters and fallback noscript, aka. "classic" ORES. All three will persist in the finished extension, and all three seem to require the same precautions to roll out on new wikis.

Yes, that's perfect! My current preference is that we generalize the config to also control "classic" ORES, if you agree?

That's fine with me. However, it sounds like your concern is "I want the infrastructure to be able to warm up before stuff is shown to users" and @Halfak and @Ladsgroup had (as I understood it at least) the slightly different concern of "I want people on the wiki to be able to see their shiny new ORES deployment without having to wait for the Collaboration team". Maybe I misunderstand one of these two things, but it seems like what you suggest would accomplish the former but not the latter. Either way is fine with me.

The main use case I'm imagining is that we're deploying a new ORES model but want to schedule the UI change independently. I'm considering the UI as composed of three parts: new ORES RC filters, Special:Contribution simple ORES filters and fallback noscript, aka. "classic" ORES. All three will persist in the finished extension, and all three seem to require the same precautions to roll out on new wikis.

That's almost but not entirely true: configuring thresholds for rich filters (and which/how many such filters should appear) is a bit more work then setting the single threshold for the boolean filter. So the RCF integration requires more configuration than the classic one (it might not sound like much, but the classic one requires so little config that we're talking about 1 setting vs 8 settings).

@Catrope Cool. I think I can paraphrase @Halfak's stake in this as "please don't make us coordinate minor details inside of our deployments, let's decouple the entire UI from however the scoring team wants to deploy models".

@jmatazzoni and I realized that the "basic"/legacy ORES filters and preferences should also be toggled by this same configuration. If Extension:ORES is deployed in pure infrastructure mode, there should be no UI changes.

awight renamed this task from Summarize what it will take to separate product and platform for ORES Extension to Summarize what it will take to separate UI and infrastructure for ORES Extension.Jul 25 2017, 7:08 AM
awight updated the task description. (Show Details)

Change 359364 merged by jenkins-bot:
[mediawiki/extensions/ORES@master] Allow filter UI to be turned off

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