Migrate and convert user preferences to the new UX
Closed, ResolvedPublic

Description

NOTE: The only action required here is for the items in bold, plus "Migrate “Classic ORES” users to New Filters ORES"


When we move users to the New Filters (either in beta or because the new UX graduates to standard), all user preferences will be migrated. This ticket explains the requirements for this process. The ticket also details how particular preference settings in the old system translate to the new one. These translation details come into play in tall the subtasks that belong to parent task T172350.

Requirements

  • The current default settings for WL and RC will be translated and established as defaults in the new UX (see Current Default Settings below).
  • When a user moves to the New Filters UX, all user preferences from the old system will be transferred to their equivalents in the new UX for that user (see below, under "Preference Conversions" for details about equivalency).
  • When New Filters users bookmark settings to the Saved Filters menu, and declare those settings Default (using the "Set as default" option), the default on-page settings override any existing page preferences that were set on the Preferences pages.
  • Many existing user preferences will no longer be visible on the consolidated "Change Monitoring" preference page (as detailed in the subtasks of T172350). However, all such hidden preferences will be stored for each user.
  • In the event a user opts out of the New Filters on RC or WL or both, all their old preferences, including the hidden ones, will be restored. (Their OLD preferences will be restored; i.e., we don't need to send on-page defaults "upstream" to be stored as hidden preferences).

Current Default Settings

The following are the existing default preferences for RC and WL. The preferences here are described as they will be implemented in the New Filters UX, except for those that do not exist in the new UX and will continue to be presented on the Preferences page.

Recent Changes
  • 7 days, 50 results.
  • Active filters = Logged edits, page creations, page edits, human (not bot)
Watchlist ( existing defaults)
  • 3 days, 250 maximum results
  • Active filters: Latest revision, Logged edits, page creations, page edits. [Note: unlike RC page, “Human (not bot)” is NOT a default]
  • Active WL pref page options: "Add pages I create and files I upload to my watchlist", "Add new files I upload to my watchlist"
Pending Changes

Currently shown on the RC Page prefs, but not really an RC Page pref. In new system, shown in its own section.

  • Active page prefs: "Use small icons and minimal text to show review status of pages", "Use the default settings for each page".

Preference Conversions

This section spells out how old-style preferences will be realized in the new UX

Recent Changes preference setting translations (non-ORES)

  • Group changes by page in recent changes and watchlist: this setting has been divided, so we need to set it for both WL and RC separately in the new UX.
  • Hide minor edits from recent changes = add “Non-minor edits” filter to defaults.
  • Hide categorization of pages = This is a current default. See "Current Default Settings" above. If UNCHECKED, add “category changes” filter to defaults.
  • Show Wikidata edits by default in recent changes and watchlist = add “Wikidata edits” to defaults. [ Not sure what to do here: this says this setting works on Watchlist and RC page, but there is ALSO a preference for Wikidata on Watchlist. So try your best to figure out how these two settings actually interact, and reproduce as best as possible]
  • “Number of edits to show in recent changes, page histories, and in logs, by default:” -- Apply setting to “changes to show” control on RC page AND to new “Number of edits to show” section of Preferences.
  • “Days to show in Recent Changes”--apply setting to Recent Days control on RC page .

Watchlist settings migration (non-ORES)

  • Expand watchlist to show all changes, not just the most recent = if checked, remove “Latest revisions” from default filter set (see above).
  • Hide minor edits from the watchlist = if checked, add “Non-minor edits” filter to defaults.
  • Hide bot edits from the watchlist = if checked, add “Human (not bot)” filter to defaults.
  • Hide my edits from the watchlist = if checked, add “Changes by others” filter to defaults.
  • Hide edits by anonymous users from the watchlist = if checked, add “Registered” filter to defaults.
  • Hide edits by logged in users from the watchlist = if checked, add “Unregistered” filter to defaults.
  • Reload the watchlist automatically whenever a filter is changed = no action required. Ignore.
  • Hide categorization of pages = this is a current default. See "Current Default Settings" above. If UNCHECKED, add “category changes” filter to defaults.
  • Show Wikidata edits in your watchlist-- if checked, add Wikidata edits” filter to defaults.
  • “Maximum number of changes to show in expanded watchlist” -- apply setting to “changes to show” control
  • “Days to show in watchlist”--apply setting to Recent Days control.

Migrate “Classic ORES” users to New Filters ORES

The Revision Scoring (ORES) settings will be translated to the new UX in the following way for both Recent Changes and Watchlist. The Prediction Threshold setting determines which filters and highlights apply.

Prediction Threshold = “May have problems”
  • If “Highlight likely problem edits” only is checked
    • Apply highlights as follows, May have problems = yellow; Likely have problems = orange; Very likely have problems = red.
  • If “Show only likely problem edits” only is checked (i.e., no highlighting)
    • Activate filter, May Have Problems (only)
  • If BOTH options are checked (highlighting and filtering)
    • Activate filter, May Have Problems
    • Apply highlights Likely have problems = orange; Very likely have problems = red. (i.e., no highlight for May).
Prediction Threshold = “Likely have problems”
  • If “Highlight likely problem edits” only is checked
    • Apply highlights as follows, Likely have problems = orange; Very likely have problems = red.
  • If “Show only likely problem edits” only is checked (i.e., no highlighting)
    • Activate filter, Likely Have Problems.
  • If BOTH options are checked (highlighting and filtering)
    • Activate filter, Likely Have Problems.
    • Apply highlights as follows: Very likely have problems = red. (i.e., no highlight for May or Likely).
Prediction Threshold = “Very likely have problems”
  • If “Highlight likely problem edits” is checked:
    • Apply highlights as follows, Very likely have problems = red. - If “Show only likely problem edits” is checked:
    • Activate filter, Very likely have problems.
  • If BOTH options are checked (highlighting and filtering)
    • Activate filter, Very likely have problems and apply highlights as follows, Very likely have problems = red (i.e., it doesn't matter if one or both are checked for this one).

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: PokestarFan. · View Herald TranscriptAug 7 2017, 10:28 PM
jmatazzoni updated the task description. (Show Details)Aug 7 2017, 10:30 PM
jmatazzoni updated the task description. (Show Details)

Clarification: this is asking for preferences to modify the base defaults (as they currently already do), not magically create a new saved filter as we previously discussed.

Most of what's in the task description is already implemented, except for the ORES part (and perhaps the anon/liu part now that that's moved?). At least on RC; not sure about WL.

jmatazzoni renamed this task from Consolidate preferences: Migrate and convert user preferences to the new UX to Migrate and convert user preferences to the new UX.Sep 18 2017, 9:19 PM

Most of what's in the task description is already implemented, except for the ORES part (and perhaps the anon/liu part now that that's moved?). At least on RC; not sure about WL.

The default for userExpLevel on Watchlist does need to be updated for this.

I don't know of any others besides that and ORES. If there are more, let's bold them.

Change 380985 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/core@master] Migrate and convert WL settings to the new UX

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

Catrope removed Petar.petkovic as the assignee of this task.
Catrope added a subscriber: Petar.petkovic.

Petar points out that his patch only does the userExpLevel part, not the ORES part.

Change 380985 merged by jenkins-bot:
[mediawiki/core@master] Migrate and convert WL settings to the new UX

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

From the ORES section

If “Show only likely problem edits” is checked: Activate filter, May Have Problems (only).

"Show only problem edits" was removed in T175611 for users with Structured Filters enabled. The threshold and highlight preferences would have been removed as well but they affect Special:Contributions.

I'm not sure about respecting preferences and are hidden and can't be changed anymore.

Change 381790 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/extensions/ORES@master] RCFilters: Respect hideNonDamaging pref on RC and WL

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

Change 381790 merged by jenkins-bot:
[mediawiki/extensions/ORES@master] RCFilters: Respect hideNonDamaging pref on RC and WL

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

Change 382162 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/extensions/ORES@master] RCFilters: highlight damaging levels

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

Change 382161 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RCFilters: Allows specifying default highlights from the server

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

Change 382161 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Allows specifying default highlights from the server

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

Change 382162 merged by jenkins-bot:
[mediawiki/extensions/ORES@master] RCFilters: highlight damaging levels

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

Change 382300 had a related patch set uploaded (by Catrope; owner: Sbisson):
[mediawiki/core@wmf/1.31.0-wmf.2] RCFilters: Allows specifying default highlights from the server

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

Change 382301 had a related patch set uploaded (by Catrope; owner: Sbisson):
[mediawiki/extensions/ORES@wmf/1.31.0-wmf.2] RCFilters: highlight damaging levels

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

Change 382300 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.2] RCFilters: Allows specifying default highlights from the server

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

Change 382301 merged by jenkins-bot:
[mediawiki/extensions/ORES@wmf/1.31.0-wmf.2] RCFilters: highlight damaging levels

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

Mentioned in SAL (#wikimedia-operations) [2017-10-04T23:36:21Z] <catrope@tin> Synchronized php-1.31.0-wmf.2/includes/changes/ChangesListFilter.php: ORES highlights for RCFilters (T172757) (duration: 00m 50s)

Mentioned in SAL (#wikimedia-operations) [2017-10-04T23:49:28Z] <catrope@tin> Synchronized php-1.31.0-wmf.2/resources/src/: ORES highlights for RCFilters (T172757) (duration: 00m 50s)

Mentioned in SAL (#wikimedia-operations) [2017-10-04T23:51:12Z] <catrope@tin> Synchronized php-1.31.0-wmf.2/extensions/ORES/includes/Hooks.php: ORES highlights for RCFilters (T172757) (duration: 00m 50s)

Etonkovidova updated the task description. (Show Details)Oct 5 2017, 9:08 PM

@SBisson, there appears to be a bug in the ORES migration features. The settings migrate to both Watchlist and RC page. You see the highlights and filters in the Active Filter area. But they don't show up in the filter menu—there, all the check boxes are empty and no highlights are showing.

jmatazzoni added a comment.EditedOct 5 2017, 10:22 PM

Also, and more pressingly, we need a plan for how to address the bigger problem: this ticket means that anyone who has the "Revision Scoring" preference for "Show only likely problem edits" selected is liable to have a problem on Watchlist, because ORES filters slow down Watchlist a lot.

This problem mostly effects en.wiki and ru.wiki, and is really only noticeable for anyone who has their prefs set to 3 days or more. Also, it appears to be a problem only for the "Show only likely problem edits" option, which invokes a filter; not for the "Highlight likely problem edits," which invokes highlighting but no filtering. But if you fall into those categories, ORES filters will crash your Watchlist. That's not good.

Can we block the ORES migration for Watchlist only?

[...]
Can we block the ORES migration for Watchlist only?

Done in https://gerrit.wikimedia.org/r/382627
It needs to be reviewed, tested, and deployed

When checking in 1.31.0-wmf.2 (enwiki) two issues

  • Preferences-Watchlist option " Highlight likely problem edits with colors and an "r" for "needs review" affects RC page. That option is not easily discoverable.
  • All three damaging filters will be displayed on RC page as highlight-only. 'Prediction threshold' levels do not affect number of damaging filters display.
Etonkovidova updated the task description. (Show Details)Oct 5 2017, 11:58 PM

@SBisson there is another bug. The "Show only likely problem edits..." option does not work on RC page. It works on Watchlist.

@SBisson there is another bug. The "Show only likely problem edits..." option does not work on RC page. It works on Watchlist.

RC has it's own preference for that, in the RC tab.

Change 382632 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/extensions/ORES@master] RCFilters: default highlight according to preference

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

jmatazzoni updated the task description. (Show Details)Oct 6 2017, 12:33 AM
Etonkovidova added a comment.EditedOct 6 2017, 12:49 AM

The table below documents present (1.31.0-wmf.2) behavior of Revision scoring settings on Preferences Watchlist

Prediction thresholdHighlight likely problem edits ...Show only likely problem edits ...Recent changesWatchlist (beta feature enabled)
default - "Likely have problems"Not enabledNot enableddefault - Human (not bot), Page edits, Page creations, Logged actionsdefault - Latest revision, Page edits, Page creations, Logged actions
default - "Likely have problems"EnabledNot enabledthree damaging filters (as highlight-only) displayedthree damaging filters (as highlight-only) displayed
default - "Likely have problems"Not enabledEnabledonly default filters displayed'Likely have problems' filter selected
"May have problems..."EnabledEnabledthree damaging filters (as highlight-only) displayed'May have problems' displayed as selected; two other damaging filters displayed as highlight-only
"May have problems..."EnabledNot enabledthree damaging filters displayed (as highlight-only)three damaging filters displayed (as highlight-only)
"May have problems..."Not enabledEnabledonly default filters displayed'May have problems' selected filter displayed

In T172757#3663053, @Etonkovidova wrote:

When checking in 1.31.0-wmf.2 (enwiki) two issues

  • All three damaging filters will be displayed on RC page as highlight-only. 'Prediction threshold' levels do not affect number of damaging filters display.

I see what you mean. E.g., I set my threshold to "very likely have problems" but still see highlighting for May and Likely. That is a problem. The highlighting and filtering should respond to the threshold, as described above. E.g., if your threshold is set to Very Likely, then only the red highlight should be set, on Very Likely. The other two should not be set.

MEANWHILE, I've realized we need to make the spec more complicated. Sorry!

What I didn't take into account before is the case of users who have selected BOTH the "Highlight" and the "Show Only..." preferences (i.e., highlighting and filtering). The issue is this: if you are filtering for May Have Problems, then you should NOT highlight May Have Problems—because all of your results meet that condition. The whole page would be yellow, which is annoying.

I've rewritten the spec above to differentiate the highlighting behavior when the user has their preferences set to both filter and highlight by default. It works well for May and Likely thresholds. (There's nothing we can do about Very Likely, so the spec for that hasn't changed.)

[...]
What I didn't take into account before is the case of users who have selected BOTH the "Highlight" and the "Show Only..." preferences (i.e., highlighting and filtering). The issue is this: if you are filtering for May Have Problems, then you should NOT highlight May Have Problems—because all of your results meet that condition. The whole page would be yellow, which is annoying.

It might be annoying but that's exactly what you get on old RC/WL with classic ORES highlight.

jmatazzoni updated the task description. (Show Details)Oct 6 2017, 4:55 PM

! In T172757#3663945, @SBisson wrote:

It might be annoying but that's exactly what you get on old RC/WL with classic ORES highlight.

It's true. But the original ORES team doesn't have the product and design muscle that our team does. Our goal throughout has been to improve on what was there before.

@SBisson, there appears to be a bug in the ORES migration features. The settings migrate to both Watchlist and RC page. You see the highlights and filters in the Active Filter area. But they don't show up in the filter menu—there, all the check boxes are empty and no highlights are showing.

While I was looking at this happening in production the other day, I can't, for the life of me, reproduce this. The behavior that I see initializes the menus correctly.
@Etonkovidova when the new fixes are done, can you add this to your testing? If you see this happen again, I'll have to delve deeper. Otherwise, it may have been a JS loading fluke?

Note: it's fixed in master by https://gerrit.wikimedia.org/r/#/c/382009 and will follow the train next week.

I added more states to the table of cases above - seems to be working according to the logic that we have now for such specs (which can be improved).

Two points of bug-like behavior

  • Any of 'Prediction threshold' options combined with 'Highlight likely problem edits ...' will display all damaging filters on RC and Watchlist
  • 'Show only likely problem edits (and hide probably good edits)' option on Watchlist is separate and, thus, not affecting RC. RC has its own option option ' Show only likely problem edits ...'. And that it's totally unclear from the Preferences-Watchlist options, especially since ' Highlight likely problem edits' affects RC and Watchlist.
  • the highlight option selection does not propagate to Filter selection menu which is addressed in https://gerrit.wikimedia.org/r/#/c/382009

Change 382632 merged by jenkins-bot:
[mediawiki/extensions/ORES@master] RCFilters: default highlight according to preference

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

[...]

  • Any of 'Prediction threshold' options combined with 'Highlight likely problem edits ...' will display all damaging filters on RC and Watchlist

The patch for this was just merged. Should be on betalabs soon.

Etonkovidova added a comment.EditedOct 13 2017, 9:22 PM

@SBisson - checked https://gerrit.wikimedia.org/r/382632 in wmf.3 and betalbs ( the fix seems to be merged). Selecting 'Prediction threshold' option will display the filters equal and below, e.g. selected 'May have problems...' option will display 'May have problems', 'Likely have problems' and 'Very likely have problems'. If 'Likely have problems' threshold option is selected, then 'Likely have problems' and 'Very likely have problems' will be displayed.

Re-checked again - it is, in fact, a correct behavior.

Etonkovidova updated the task description. (Show Details)Oct 16 2017, 7:56 PM
Etonkovidova added a comment.EditedOct 16 2017, 8:38 PM

All specs are in place, except “Show only likely problem edits” in Watchlist preferences - the option was disabled due to performance considerations. It works again in betalabs now and since it was filed as a separate ticket (T178202: [wmf.3 - regression] Selecting Watchlist preference - 'Show only likely problem edits...' does not affect default filter selection ), I'll check when it will be deployed to production.

Also, the following may be moved to a separate task if we still need it?

Many existing user preferences will no longer be visible on the consolidated "Change >Monitoring" preference page (as detailed in the subtasks of T172350). However, all such >hidden preferences will be stored for each user.

The following spec is not implemented yet - there is no Preference -Watchlist option that allows to set it as a user preference.

Group changes by page in recent changes and watchlist: this setting has been divided, so >we need to set it for both WL and RC separately in the new UX.

QA Recommendation: Product should weigh in

Etonkovidova updated the task description. (Show Details)Oct 16 2017, 8:47 PM
jmatazzoni updated the task description. (Show Details)Oct 16 2017, 9:41 PM
Etonkovidova updated the task description. (Show Details)Oct 16 2017, 9:50 PM
jmatazzoni closed this task as Resolved.Nov 21 2017, 6:25 PM