@Pginer-WMF @Mooeypoo @Halfak, please see discussion above for Hide probably good edits from recent changes. Thoughts or opinions?

The above list of preferences is for en.wiki. I don't know if these are standard or not. I checked Portuguese Wikipedia and Polish Wikipedia and all the preferences were the same, except that "Hide probably good edits from recent changes" was translated (by Google) as "Hide checked edits on recent changes." I'm guessing that is a translation error?

@Catrope or @SBisson, are these options standard? Or do we have to check each wiki?

@jmatazzoni suggested "Hide probably good edits from recent changes" could be a hidden preference, controlled directly on the RC page.

I mentioned the idea of a drop-down box on Special:Preferences, with:

• Very likely good
• Very likely have problems
• Likely have problems
• May have problems
• Show all edits

If I understand correctly, the existing "Hide probably good edits" can be mapped to "May have problems". "Show all edits" just means "don't filter by ORES damaging by default". This suggestion would not affect the UI for RC, only what was selected by default.

However, I'm also fine with a hidden preference controlled directly on the page. If so, the only question is whether adding this hidden preference is a blocker for the MVP. If not, people might be a little disappointed that the preference stops working, but not sure if it's a big deal.

@jmatazzoni that option does control the sensitivity on all pages. I believe that it would make sense to keep this option but specifically state that it only affects non-RC change lists.

@Ladsgroup, thoughts?

Thanks Aaron. I amended the Description above to account for that functionality.

Matt writes:

If I understand correctly, the existing "Hide probably good edits" can be mapped to "May have problems".

You're brilliant. I thought we had to use all three filters to exclude the 4th, but we don't, because ORES groups work differently than the other groups. Making use of May have problems is a very reasonable solution that requires us to only put one new default filter on the page, not three as I'd thought. I'll update the Description to reflect this.

@jmatazzoni suggested "Hide probably good edits from recent changes" could be a hidden preference, controlled directly on the RC page

I think what I might have referred to is not a hidden preference but a new feature Pau is working on that will let users name and save different personal settings for this page. When we have that feature, then we might want to consider dropping some of the preferences (or not).

Worth noting that "Group changes by page" will affect the highlighting implementation at least somewhat, since it completely changes the format of the result list.

Does anyone know if there will be variation across the various ORES-enabled wikis as to a) what RC page Preferences are offered and b) what the default settings are?

I started a spreadsheet to check across them all, but didn't finish it.

That's not something I could help with. But maybe @Ladsgroup has an idea.

I think the only things that need to be done here are "ORES sensitivity" and answering Joe's question (looking at wmf-config).

@jmatazzoni please review the following:

Hide categorization of pages This is selected by default. If it was UNSELECTED by existing ORES users or is UNSELECTED by new users, activate the following filter and display it as a default in the Active Filter Display Area: Category changes.

In case when 'Hide categorization of pages' is unselected, the default filters will be reduced to only 'Human (not bot)' because it will add hidecategorization=0 ('Category changes') and along with 'Page edits', 'Page creations', and 'Logged actions' it will be full coverage for the group 'Type of change'. Thus, only the 'Human (not bot)' filter will be displayed.

In T150059#3100375, @Etonkovidova wrote:

Hide categorization of pages This is selected by default. If it was UNSELECTED by existing ORES users or is UNSELECTED by new users, activate the following filter and display it as a default in the Active Filter Display Area: Category changes.

In case when 'Hide categorization of pages' is unselected...it will be full coverage for the group 'Type of change'.

This is a very interesting and advanced point. I think what Elena meant to say is that if the Category preference gets unselected by a beta user AND the Wikidata preference gets selected, then that specific combo of default settings puts Type of Change into full coverage. That means such a user would come to a default filter lineup showing 6 filters, 5 of which would be grayed out because they are in a "No Effect" state. On the other hand, she is getting exactly what she asked for.

We could, in theory, define a special rule that would, for this one specific default settings combination, deselect all the Type of Change filters instead of selecting them all. @Pginer-WMF, what do you think? How confusing will this lineup of grayed out filters be?

In T150059#3100631, @jmatazzoni wrote:

In T150059#3100375, @Etonkovidova wrote:

Hide categorization of pages This is selected by default. If it was UNSELECTED by existing ORES users or is UNSELECTED by new users, activate the following filter and display it as a default in the Active Filter Display Area: Category changes.

In case when 'Hide categorization of pages' is unselected...it will be full coverage for the group 'Type of change'.

This is a very interesting and advanced point. I think what Elena meant to say is that if the Category preference gets unselected by a beta user AND the Wikidata preference gets selected, then that specific combo of default settings puts Type of Change into full coverage. That means such a user would come to a default filter lineup showing 6 filters, 5 of which would be grayed out because they are in a "No Effect" state.

Elena is right. Since this is a full-coverage group, everything (Page edits, Page creations, Category changes, Logged actions) being included means the group has no effect. Thus, it is not shown in Active filters, and when you open the drop-down everything is unchecked. This applies regardless of how you get there (either preferences and plain Special:RecentChanges, or directly via an explicit URL with parameters).

Basically, it already works (tested locally) as you suggest, except it's for all full coverage groups.

@Mattflaschen-WMF commented:

...means the group has no effect. Thus, it is not shown in Active filters,

It's great that this is how it works in this instance, but where was such functionality specified? In T149391, under "No Effect Display States," it says that in the case of "no-effect" filter combinations, all the filters will be shown in the Active Filter area but they'll be grayed out and special tooltips shown.

Will that still happen if the user makes the choices actively as opposed to doing it through defaults? Did you, in other words, make special provision for when this happens via the defaults?

In T150059#3100678, @jmatazzoni wrote:

Will that still happen if the user makes the choices actively as opposed to doing it through defaults?

If you get to this state by clicking boxes (e.g. checking both 'Minor edits' and 'Non-minor edits', both of which already default to "not hidden"), it will grey as you described.

However, if you go to /wiki/Special:RecentChanges?hideminor=0&hidemajor=0 (or just refresh after doing the checking above), it will then not show them.

So there is indeed a difference depending on whether it's directly done by the user in this session/page load, or via the URL/preferences (URL and preferences behave the same here)

Oh, cool. Great job!

The "makes the choices actively"/grey no-effect is much more of a front-end thing, so credit to Moriel and anyone else who worked on that aspect (though my back-end registers the full-coverage/default/preference information)

In T150059#3100631, @jmatazzoni wrote:

We could, in theory, define a special rule that would, for this one specific default settings combination, deselect all the Type of Change filters instead of selecting them all. @Pginer-WMF, what do you think? How confusing will this lineup of grayed out filters be?

I think that simplifying the selection to show only the relevant filters seems right (as it seems already the case from the subsequent comments).

(1)
@Pginer-WMF

I think that simplifying the selection to show only the relevant filters seems right.

The current RC page displays user selection of preferences made via Preferences-Recent changes, so users are informed what filters are applied to the displayed set of results. If a user selects

The selected preferences will be displayed on RC page:

Now, with New RC filters, changes to preferences that made on Preferences-Recent changes are not displayed on RC page - except for Wikidata and Minor edits.
So, if a user makes the same selection on Preferences-Recent changes as in the previous example, the result on RC page will not inform users that 'Category changes' are not displayed, 'Wikidata' is shown, and 'probably good edits' are not shown.

(2) @jmatazzoni - the following spec, which was discussed above, is simply not done. If the current behavior is what is expected - as soon as 'Hide categorization of pages' on Preferences-Recent changes is deselected, the default filters will be 'Human (not bot)' and this will be the only filter displayed in the filter are - then the spec needs to be updated.

Hide categorization of pages This is selected by default. If it was UNSELECTED by existing ORES users or is UNSELECTED by new users, activate the following filter and display it as a default in the Active Filter Display Area: Category changes.

Thanks Elena for the note about Categorization. This is a result of us handling the filters differently when they are selected in Prefs vs. when they are selected in the interface by the user. While that is odd, I think it is OK and has the upside of the user not seeing a whole raft of default filters that are grayed out.

To summarize

• all specs that marked with green checkmarks have been fully implemented
• two open questions: (1) the Preferences-Recent changes settings - should they be visible to users on RC page , especially if they affect the default filters set? Besides the case with 'Hide categorization of pages' option (which may make more sense when 'Wikidata' will be implemented, there is 'Hide patrolled edits on cawiki and, probably, other wikis' which may have different set of 'Advanced options' in Preferences-Recent changes

(2) Wikidata filter and RC preference setting needs to be checked when Wikidata filter will be implemented.

QA recommendation: Product should weigh in.

This all looks correct, though @Etonkovidova will make a note to go back and test once the Wikidata filter has been included. Resolving this!