Hi @Mduvekot, thanks for taking the time to report this!
Which exact versions of MediaWiki and PageCuration have you installed? (Or is this about English Wikipedia?)

In T169244#3391488, @Aklapper wrote:

Hi @Mduvekot, thanks for taking the time to report this!
Which exact versions of MediaWiki and PageCuration have you installed? (Or is this about English Wikipedia?)

I use enwiki.

Perhaps that selection means "show me pages that are either unreviewed or have been nominated for deletion"?

In T169244#3449008, @Catrope wrote:

Perhaps that selection means "show me pages that are either unreviewed or have been nominated for deletion"?

If it does mean that it's still broken because deselecting Nominated for deletion also shows deleted pages.

@Catrope In that case it's inconsistent with the other three filters in the same UI (unreviewed, reviewed, redirects), which at the moment function correctly.

This was brought up again in community testing related to this project. Moving to Growth team's board so we can triage.

"Nominated for deletion" (as well as "Redirects") works by excluding those pages unless it is explicitly checked, in which case it includes them but never shows only them.

From the look of the code, it looks like it's deliberate. It certainly feels like a bug but it's actually an unintuitive feature that appears to be like that since 2012.

It is easy to change but unless we do a complete redesign of the 'State" group it will be a breaking change for some users.

@SBisson -- I made a truth table to make sure I understand this.

The table shows what happens with different boxes checked. "Unreviewed" could be swapped for "Reviewed" and "Nom for deletion" could be swapped for "Redirects".

It sounds like you're saying that with the planned change, we would be breaking the use case of "A, no B" in the upper right?

I can't stress enough that this is an issue that needs fixing. Being able to filter only redirects is functionality that we should have. Same for 'nominated for deletion'.

Related tasks:

• T42135: Make "redirects" included by default in PageTriage
• T49471: Cannot set filter using just Nomination for deletion or Redirects

After discussing with reviewers here, and after talking with @SBisson and @Etonkovidova, we've decided to go with the following implementation.

• We separate the "reviewed/unreviewed" dimension from the type of page. We do this by adding a new section called "Type" that has checkboxes for "Nominated for deletion", "Redirects", and "All others" (we would need a better word for this last type -- I am trying to say "normal" pages).
• Within the "State" or "Type" sections, the logic is "OR", and across the two sections it is "AND". This accounts for the fact they are different dimensions.
• Then a reviewer could generate any of the 21 possible combinations. For instance, by checking "Unreviewed", "Nominated for deletion", and "All others", a reviewer would have a list of all pages, including those nominated for deletion, that are unreviewed. Or by checking "Unreviewed", "Reviewed", and "All others", a reviewer would have a list of all pages, excluding redirects and nominated for deletion, that are any review status.
• At least one box must be checked in both those top two sections.
• All the things in the "That" section could be layered on top of the selection from the two checkbox sections.
• The new type section should be represented in the "filter logic" as its own phrase, like so: Namespace (Article), State (Reviewed, Unreviewed), Type (Nominated for deletion, All others).
• The default selection for a new user should be: Namespace (Article), State (Reviewed, Unreviewed), Type (Nominated for deletion, All others).
• Existing defaults set by existing reviewers should be mapped to the new logic. Let's discuss if this non-trivial.

Here is a mockup:

Change 462572 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/extensions/PageTriage@master] Split state and type filters

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

@SBisson -- that was fast! Which train will this be in, such that @Etonkovidova and I (and community members!) will be able to try this out in Test Wiki?

In T169244#4612533, @MMiller_WMF wrote:

@SBisson -- that was fast! Which train will this be in, such that @Etonkovidova and I (and community members!) will be able to try this out in Test Wiki?

The patch is not finished.

It should be in next week's train. We can't tell for sure until it's merged.

@SBisson -- got it. This is a change that I would like community members to be able to try in Test Wiki before it goes to production in English Wikipedia. Can we arrange things so that's possible? Will that mean feature flags? Or should we just try to do it over the course of the week that the train runs?

In T169244#4612567, @MMiller_WMF wrote:

@SBisson -- got it. This is a change that I would like community members to be able to try in Test Wiki before it goes to production in English Wikipedia. Can we arrange things so that's possible? Will that mean feature flags? Or should we just try to do it over the course of the week that the train runs?

This is not an easy one to feature toggle... but I can try if the schedule below is not acceptable.

If we merge on a Tuesday afternoon, you and Elena have 6 days to test it until it reaches testwiki on the next Tuesday morning. Then, community members have Tuesday and Wednesday to test it until it reaches enwiki on Thursday. We can always revert the change before it hits enwiki or shortly after if there are issues with the feature or community response.

@SBisson -- That schedule sounds fine. I think the reviewers will be able to do a quick turnaround on testing when we ask them to, so we won't need a feature flag.

In T169244#4608074, @MMiller_WMF wrote:

[...]

• Existing defaults set by existing reviewers should be mapped to the new logic. Let's discuss if this non-trivial.

I can do something like that:

1. For users who DON'T have "nominated for deletion" or "redirects" selected, select "all others".
2. For users who DO have "nominated for deletion" and/or "redirects" selected, leave it. They will see less results than they are used to because those options do not include other pages anymore but I think they will open the filter menu and figure out pretty quickly that the filters have changed and what the new option "All others" mean.

Alternatively, we could drop the saved filters for all users (there's only 4976 of them). They would all get the default. It's the simplest option and probably a very minor annoyance.

@SBisson -- I think we should migrate the defaults because most people who use the feed are probably not going to hear the news that the feed changed, and I think the disruption of their defaults will be too silent. But a question about #2 (For users who DO have...). We can reproduce what they currently have using the improved filters, right? If you have "nominated for deletion" and/or "redirects" selected, leave it, and also select "All others". That will give them the same set of pages, right?

In T169244#4616497, @MMiller_WMF wrote:

@SBisson -- I think we should migrate the defaults because most people who use the feed are probably not going to hear the news that the feed changed, and I think the disruption of their defaults will be too silent. But a question about #2 (For users who DO have...).

We can reproduce what they currently have using the improved filters, right? If you have "nominated for deletion" and/or "redirects" selected, leave it, and also select "All others". That will give them the same set of pages, right?

Yes we can but it is starting to be complex: when they load the page, we don't know if they have only "nominated for deletion" because that's what they used to have of if they have been migrated and then selected that. In other words, we have to introduce versioning to their saved filters to keep track of who's been migrated and who hasn't.

It's all doable, we've done exactly that for RCFilters, but it is more complexity and I'm wondering if it's worth it.

I think the feed UI is pretty transparent about what it is showing with the filters summary line and the stats (top-right, and bottom-left). I wonder how many would notice that they've gone back to the default, and as soon as they change the filters it would be sticky again, so not enough time to file a bug report, merely a glitch.

I implemented saved filter options versioning and migration so I can move this to "code review".

@SBisson -- okay, if you've already gone and implemented, then great. If it is a risk you think we shouldn't take, then I can explain to the community when we roll it out that sticky settings will be gone. Let me know your preference.

Change 462572 merged by jenkins-bot:
[mediawiki/extensions/PageTriage@master] Split state and type filters

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

@SBisson -- will this go to Test Wiki on Monday? And did you end up implementing the ability to keep the sticky filter/sort settings?

Checked in betalabs - the filters' logic seems to be accurate. I am having general problems with Page Curation tool - i.e. cannot submit any page in User namespace for Page triage, and cannot mark a page for deletion. I'll need to sort such issues out with @SBisson on Mon whether is just betalabs limitations or something else.

In T169244#4626387, @MMiller_WMF wrote:

@SBisson -- will this go to Test Wiki on Monday? And did you end up implementing the ability to keep the sticky filter/sort settings?

This will go to testwiki on Tuesday, and enwiki on Thursday. I implemented the migration of saved filters so there should be no surprises to the list of pages people see by default.