Rationalize ORES preferences on Recent Changes and Watchlist prefs pages
Closed, ResolvedPublic

Description

Right now there are a number of inconsistencies in the way we handle the ORES preferences on the Recent Changes and Watchlist preference pages (documented in T178098). Many of these complexities have to do with how we hide and show some but not all tools based on whether the New Filters are active or not. This was going to be cleaned up in the Preference Consolidation (T172350), but that has been deferred.

Meanwhile, we recently made it so that the New Filters interpret ORES preferences in New Filters terms (T172757), meaning these controls now make sense whether the New Filters are active or not (due to whether the user has opted out, whether she has the beta, or for any other reasons. ) This allows us to simplify the preferences, rationalize them, and stop all the hide/showing.

This ticket describes how we will rationalize these choices by making ORES preferences for WL and RC page completely independent. We'll do this by making it so that no WL prefs affect RC page. Meanwhile, we'll put a full set of Revision Scoring controls on the RC prefs page. Here are the details:

Changes to make to the Prefs

Watchlist prefs

We will make it so that Watchlist prefs page ORES prefs apply only to Watchlist, by doing the following:

- Make it so "Highlight likely problem edits " on WL prefs affects only WL, no matter what the New Filters status is. (Currently, when New Filters are active, this controls RC page, etc.)
- Make so that "Prediction Threshold" selector on WL prefs affects only WL (unlike now)

  • Naturally, all existing settings will be preserved and migrated to the new controls. E.g., if the user had set "Highlight likely problem edits" to active on RC page by using the WL prefs, that user's setting will be preserved and will be reflected on the new control we are adding to the RC Prefs page--see below.

    - Edited UI texts (copy these to get all changes):
    • Revision scoring on Watchlist [section title]
    • Change the "threshold" setting to make the options below broader or more selective. [instruction text]

Recent Changes prefs

ORES settings on RC page will continue to control RC page Contributions and Related Changes, but they will no longer come and go based on whether the New Filters are active. We will be more consistent and explicit about all that by doing the following:

- Add a "Revision Scoring" section on the RC prefs page.

  • Position: above Pending changes section, if possible.
  • Includes: Section title, Prediction threshold control, "Highlight likely problem edits" control, "Show only likely problem edits" control, instruction text.
  • "Prediction Threshold" selector and other Rev Scoring tools control RC page, Related Changes, Contributions.
  • Stop "Highlight likely problem edits " from disappearing when New Filters are active. Make it stay visible all the time.

- Edited UI texts (copy these to get all changes):

  • Revision scoring on Recent changes, Related changes, Contributions [section title]
  • Change the "threshold" setting to make the options below broader or more selective. [instruction text]
  • Highlight likely problem edits with colors and an "r" for "needs review"
  • Show only likely problem edits (and hide probably good edits)
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptNov 18 2017, 2:35 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
jmatazzoni renamed this task from Rationalize ORES preferences for Recent Changes and Watchlist to Rationalize ORES preferences on Recent Changes and Watchlist prefs pages.Nov 18 2017, 2:35 AM
jmatazzoni updated the task description. (Show Details)
jmatazzoni updated the task description. (Show Details)
jmatazzoni updated the task description. (Show Details)Nov 18 2017, 2:44 AM
jmatazzoni added subscribers: awight, Halfak, Ladsgroup.
jmatazzoni updated the task description. (Show Details)Nov 18 2017, 2:54 AM
jmatazzoni updated the task description. (Show Details)Nov 20 2017, 4:35 PM
jmatazzoni updated the task description. (Show Details)

Change 392452 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ORES@master] [WIP] Split WL and RC prefs for ORES

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

@Etonkovidova and @Petar.petkovic, FYI: I am pasting below my documentation—from a precursor ticket to this one (now closed)—of the current status quo for ORES preferences. It details the existing situation on WL and RC pages and how it differs when the New Filters are active vs. inactive. You may find it useful.

Status Quo with New Filters ACTIVE for RC page

RC Prefs page
  • "Show only likely problem edits" is visible and works
  • ("Highlight likely problem edits " is in hidden.)

But meanwhile,

WL Prefs page
  • "Highlight likely problem edits " on WL prefs DOES affect RC page but...
  • "Show only likely problem edits" on WL prefs has does NOT affect RC page.

Status Quo with New Filters INACTIVE for RC page

RC Prefs page
  • "Show only likely problem edits" is visible and works
  • "Highlight likely problem edits " is in visible and works

But meanwhile,

WL Prefs page
  • "Highlight likely problem edits " on WL prefs does NOT affect RC page
  • "Show only likely problem edits" on WL prefs has does NOT affect RC page.
  • "Prediction Threshold" selector DOES affect RC page

Revision scoring on Recent changes, Related changes, Contributions

I don't think these should be capitalized. Compare with "visual editor".

Revision scoring on Recent changes, Related changes, Contributions

I don't think these should be capitalized. Compare with "visual editor".

Agreed, and they're not capitalized in the descriptions of other preferences on the same tab either.

! In T180866#3787430, @Nikerabbit wrote:

I don't think these should be capitalized. Compare with "visual editor".

Please leave as written. If we say that this section controls revision scoring of "contributions," that is quite ambiguous and potentially confusing. E.g., "Contributions" is a page, with a name, but "contributions" could be everything.

Change 392452 merged by jenkins-bot:
[mediawiki/extensions/ORES@master] Split WL and RC prefs for ORES

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

I don't think these should be capitalized. Compare with "visual editor".

Please leave as written. If we say that this section controls revision scoring of "contributions," that is quite ambiguous and potentially confusing. E.g., "Contributions" is a page, with a name, but "contributions" could be everything.

Adding the word pages, to make it explicit to avoid any confusion, would help translators too.

Etonkovidova updated the task description. (Show Details)Dec 1 2017, 12:35 AM
Etonkovidova updated the task description. (Show Details)Dec 1 2017, 12:38 AM

Everything was checked (marked with green check marks).

@jmatazzoni
Related changes do not have ORES filters. Related pages without new filters also does not have ORES related option. Are we going to add such filters to Related pages?

QA Recommendation: Resolve

In T180866#3801687, @Etonkovidova wrote:

@jmatazzoni
Related changes do not have ORES filters. Related pages without new filters also does not have ORES related option. Are we going to add such filters to Related pages?

Yes, this ticket puts the ORES filters back onto Related Changes. T179718 I'm told the reason we originally pulled them from there has been fixed, so it should not be a problem. @Petar.petkovic, please confirm that when T179718 is implemented, the Revision Scoring preferences will apply there?

Also, Elena, how did you look at the prefs page?

Change 394611 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ORES@master] Use ORES preference on Related Changes page

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

Petar.petkovic added a comment.EditedDec 1 2017, 5:49 PM
In T180866#3801687, @Etonkovidova wrote:

@jmatazzoni
Related changes do not have ORES filters. Related pages without new filters also does not have ORES related option. Are we going to add such filters to Related pages?

Yes, this ticket puts the ORES filters back onto Related Changes. T179718 I'm told the reason we originally pulled them from there has been fixed, so it should not be a problem. @Petar.petkovic, please confirm that when T179718 is implemented, the Revision Scoring preferences will apply there?

I have published a patch to apply the same preference on both Recent Changes and Related Changes. Initially, no preference was applied on Related Changes, since ORES is still not enabled there. It's a one line change in code, and since it seems T179718 will not be completed very soon, I'm not moving this ticket to "Needs review" column.

Change 394611 merged by jenkins-bot:
[mediawiki/extensions/ORES@master] Use ORES preference on Related Changes page

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

In T180866#3801687, @Etonkovidova wrote:

@jmatazzoni
Related changes do not have ORES filters. Related pages without new filters also does not have ORES related option. Are we going to add such filters to Related pages?

Yes, this ticket puts the ORES filters back onto Related Changes. T179718 I'm told the reason we originally pulled them from there has been fixed, so it should not be a problem. @Petar.petkovic, please confirm that when T179718 is implemented, the Revision Scoring preferences will apply there?

I have published a patch to apply the same preference on both Recent Changes and Related Changes. Initially, no preference was applied on Related Changes, since ORES is still not enabled there. It's a one line change in code, and since it seems T179718 will not be completed very soon, I'm not moving this ticket to "Needs review" column.

It turned out that no changes were needed. Same preference will apply on Related Changes when enabled.

jmatazzoni closed this task as Resolved.Dec 1 2017, 7:10 PM

Great work. Thanks for completing.

I spoke in the past that we probably should run maintenance script to make newly introduced preferences for Recent changes, Related changes and Contributions, be the same as preferences for Watchlist, that were only preferences existing before this change.

In hope to get definite answer, I ask same question again. Should we migrate preferences, or maybe now it's late for that?

@Petar.petkovic. I'm not positive I understand the question. Are you saying that when this task was deployed two weeks ago, we wiped out some people's preferences? I.e., that people who had preferences via the old UI did not get the equivalent functionality when we changed the UI?

If so, I'm sorry I didn't spell out that such a migration should have been part of this task. Whether we should now do the migration is a tough call, since I suppose people might have moved on and changed their preferences again.

Is that what you're asking? If so, what is your opinion? @Etonkovidova, what about you? @SBisson?

@Petar.petkovic. I'm not positive I understand the question. Are you saying that when this task was deployed two weeks ago, we wiped out some people's preferences? I.e., that people who had preferences via the old UI did not get the equivalent functionality when we changed the UI?

If so, I'm sorry I didn't spell out that such a migration should have been part of this task. Whether we should now do the migration is a tough call, since I suppose people might have moved on and changed their preferences again.

Is that what you're asking? If so, what is your opinion? @Etonkovidova, what about you? @SBisson?

No preferences are wiped out after this task was deployed. The preferences set though the old UI are not touched.

But, we have introduced new preferences, essentially providing same set of preferences twice: one group for Recent Changes and the other for Watchlist. Before this change, we had 1) Prediction threshold, 2) Highlight likely problem edits, 3) Show only likely problem edits, but only on Watchlist. Now, we duplicated the same preferences, with the only difference being the pages where the preference is used. So, we have that set of preferences on RC and WL pages.

Before this patch is deployed, we only had options for WL, and users might have changed the preferences, not using default values any longer. But, after the patch is introduced, we have new preferences that haven't existed before (that affect RC page), which are very similar to the pre-existing ones (for WL page). Those newly introduced preferences will be set to default values.

The question is whether we want new preferences (for RC) to be mirrored from those that were existing on WL page. That would mean: if you have non-default ORES preference for WL page, and corresponding preference for RC page is unset (using default value), change RC preference to match the preference for WL. This means that if new preference for RC is changed in last two weeks since this patch is deployed, we don't touch it. We don't want to mess with user preferences like that.

jmatazzoni added a comment.EditedJan 3 2018, 8:10 PM

In T180866#3859409, @Petar.petkovic wrote:

...The question is whether we want new preferences (for RC) to be mirrored from those that were existing on WL page. That would mean: if you have non-default ORES preference for WL page, and corresponding preference for RC page is unset (using default value), change RC preference to match the preference for WL. This means that if new preference for RC is changed in last two weeks since this patch is deployed, we don't touch it. We don't want to mess with user preferences like that.

The answer, I think, is yes. The previous status quo was complicated, as documented in my summary below (pulled from T178098). The ideal solution would have been that after our changes, users had all their previous settings translated and migrated to the new UI. So, for example, before you made your changes, "Highlight likely problem edits " on WL prefs also controlled that function on RC page (for users who do have the New Filters). So, in the new UI, users who had that option turned on in the WL prefs would also have it turned on in the newly created RC page pref.

If that can still be done—without overriding any explicit preference changes users have made subsequent to our UI upgrade—then that would be ideal. If it can't or is too complicated, then just insert the default settings into any newly created preferences and let's move on.

Does that answer your question?

For reference, here's how the filters worked previous to our changes

Here is what the status quo ante was.

With New Filters ON for RC page

RC Prefs page
  • "Show only likely problem edits" is visible and works
  • ("Highlight likely problem edits " is in hidden.)

But meanwhile,

WL Prefs page
  • "Highlight likely problem edits " on WL prefs DOES affect RC page but...
  • "Show only likely problem edits" on WL prefs has does NOT affect RC page.

With New Filters OFF for RC page

RC Prefs page
  • "Show only likely problem edits" is visible and works
  • "Highlight likely problem edits " is in visible and works

But meanwhile,

WL Prefs page
  • "Highlight likely problem edits " on WL prefs does NOT affect RC page
  • "Show only likely problem edits" on WL prefs has does NOT affect RC page.
  • "Prediction Threshold" selector DOES affect RC page

If that can still be done—without overriding any explicit preference changes users have made subsequent to our UI upgrade—then that would be ideal. If it can't or is too complicated, then just insert the default settings into any newly created preferences and let's move on.

Default settings are already in place for new preferences group for RC, and match default values for WL (that were existing even before this patch).

Does that answer your question?

Yes, my question is answered.

@Catrope, @SBisson, when can we do this?

@Catrope, @SBisson, when can we do this?

I think maintenance scripts can now be added to SWAT (and performed by deployer) but I haven't done it so I might be wrong. Otherwise, someone like Roan with prod access can do it pretty much any time.

You can build and test the right command locally. I think mediawiki/maintenance/initUserPreference.php would do the job.