While it makes sense for each tool to have specific defaults, I strongly oppose the saved filters to be fragmented across tools.

Saved filters capture sets of contributions of interest for the user. These general streams/feeds of contributions are useful to analyse through different tools, existing (Recent Changes, New Page patrol, Watchlist, Contributions, Huggle, etc.) and future (e.g., visualise the new activity or the backlog size for those types of contributions in new editing dashboards). This is an opportunity to reduce the fragmentation across tools, facilitating users to move from reviewing edits to reviewing new pages more fluently, therefore encouraging to do so.

What is proposed currently in this ticket seems a much more limited and limiting approach for not very convincing reasons:

• When discussing with engineers it seemed that keeping the saved filters global across tools didn't add much complexity.
• Research suggested that users don't seem likely to add many saved filters, so keeping them in a unified list (even if there are some that are only useful in specific tools) does not seem very problematic.
• Different tools may provide different filters but that can be mapped easily and the adaptation is understandable in the context (e.g., Watchlist page ignoring the not-in-watchlist filter).

I +1 Pau.

Sorry. I thought I heard support in the Monday meeting for separating the filters. Matt in particular seemed to strongly take that position. Let's discuss again. But I do think you're minimizing both the complexity for us and for users.

I think what we heard from users in testing is that they're not that excited in general about filters on Watchlist. So all these features are for a minority of power users. For those who do use this, though, it's easy to imagine that they will have some filters they like on RC and some they like on WL. So having those two sets jumbled together, with no way to distinguish them except by the name, seems messy to me. And even if they do want the same filter set in both places, setting each one up is a matter of a few seconds of work, so not a big deal Also, I'm really not sure how we make it clear in the interface that all your filters work in both places except your defaults, which can be different in both places. Or rather, I'm sure you can explain it with some kind of popup or whatever, but it doesn't seem worth the effort of doing so to me. We need to be pressing forward with all this or we won't make our goals.

For developers, I feel like we're committing to a path that may get more and more complex as we go forward. It seems likely that once we put Watchlist out there, people will start asking for Watchlist specific filters and features. I.e., it seems quite possible that the toolsets will diverge more over time, which will lead to a mapping process of ever-growing complexity

So, I suppose that my position in a nutshell is that there's more potential for complexity and ongoing work. And the utility of that extra complexity to me is small or perhaps negative. So it feels safer and simpler to just make these separate.

In T171218#3461060, @jmatazzoni wrote:

For those who do use this, though, it's easy to imagine that they will have some filters they like on RC and some they like on WL.

I think it would be useful to capture those cases in more specific examples. In the abstract the same can be argued against having global preferences, cross-wiki notifications or shared browser bookmarks across different devices.

Also, I'm really not sure how we make it clear in the interface that all your filters work in both places except your defaults, which can be different in both places.

Making the "Set as default" action to use a more page-specific label (such as "Set as default for Recent Changes page" and "Set as default for your Watchlist") may be enough.

OK, after another team meeting on this subject, we did in fact decide to go with separate RC and WL saved settings function. So I've updated and amplified the description, and am moving this back to RFP.

Change 372187 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] [WIP] Enable RCFilters app on Watchlist

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

Change 372187 merged by jenkins-bot:
[mediawiki/core@master] Enable RCFilters app on Watchlist

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

Checked in betalabs

• Watchlist 'Saved filters' are completely separate from RC page 'Saved filters'
• Copying url for a saved filter (or url for filters/highlight/date range/number of changes displayed) from RC page to Watchilst page does not present any problems - the changes will be displayed as on RC page but with additional filtering for Watched pages
• Regarding the discussion on having the same Saved filters for Watchlist and RC page: as long as we have different user Preferences for Watchlist and Recent changes, it may be confusing to have the same saved filters display different things on RC page and Watchlist.

QA Recommendation: Resolve