I think we'll want to add a feature flag that puts RCFilters in either beta mode or default mode. That would make it easier to roll out the beta graduation to different wikis over the course of several weeks, as we plan to do.

Change 373384 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Provide an opt-out preference for New Filters for RecentChanges

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

Change 373384 merged by jenkins-bot:
[mediawiki/core@master] Provide an opt-out preference for New Filters for RecentChanges

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

I see that the layout as shown above was not implemented. Roan says it's probably not possible, so I've crossed out that requirement above and created a new subtask for the design in T175765.

Checked in betalabs

QA Recommendation: Resolve

@Jdforrester-WMF, will it be relatively easy for us to get data on the users take us up on this opt out? E.g., how many are there, on which wikis, when... etc.? Also, will there be a way to follow up and find out why people opted out?

If these things will not be possible by default, how hard is it to make it so we can do them? Should I write a subtask?

In T168376#3605940, @jmatazzoni wrote:

@Jdforrester-WMF, will it be relatively easy for us to get data on the users take us up on this opt out? E.g., how many are there, on which wikis, when... etc.?

Yes, trivial to manually pull this from the DB (though it's not actively monitored, so we won't see this over time; if you want a dashboard of this it's a bit more work).

Also, will there be a way to follow up and find out why people opted out?

Well, we'll know who they are, but that's private data (settings are private) so we can't e.g. ask them on their talk pages why they didn't like it. We could theoretically give them a pop-up asking why, but if they don't like new things that's likely to make them unhappy too.