Create new RC Filters group for 'Flagged Revisions', based on the old 'Hide reviewed edits' function
Open, Needs TriagePublic8 Story Points

Description

There is an old-style filter called "Hide reviewed edits" on some (but not all?!) FlaggedRevs wikis, which can be seen at https://als.wikipedia.org/w/index.php?title=Spezial:Letschti_%C3%84nderige&uselang=en. This task describes a new filter set based on the same idea, and which will be available on the same wikis.

[Functionality]

  • The filter enables users to identify edits subject to Flagged Revisions that need review or have already been reviewed.
  • It will go on all the wikis that currently have the "Hide reviewed edits" function (there is a list below but Matt says this can be specified programmatically with a "where available" type function).
  • Although this is related to the "Patrolled" filter, it will be a distinct filter group. This is because the two rely on different mechanisms and are available on different wikis to users with different rights on those wikis.
  • When Deferred Changes goes through, it would be great if this filter could also detect edits that are "deferred," since that function uses the same mechanism. (Unless people think it's worth it to distinguish Deferred Changes from Flagged Revisions--maybe with a fourth filter option in the group?)

[Interface / language]

Flagged revisions

Need review
Edits requiring review.

Reviewed
Edits that have been reviewed.

Not subject to review
Changes of all types that don't require review.

  • James suggest we call the group "Flagged Revisions" and then add a translator note saying "use the word here you use for Flagged Revisions." (E.g., on English Wikipedia, it will be "Pending changes".)
NOTE: Due to T150086: Don't autopatrol autoreviewed users in protection-based configs we know reviewing something doesn't always mark it patrolled (at least on certain configs), because while marking something as reviewed and marking something as patrolled require roughly similar levels of trust, being exempt from FR review (i.e. your edits are automatically published without human intervention; the autoreview right) is typically considered to require a lower level of trust than being exempt from patrolling (i.e. your edits are automatically marked as patrolled, and no patrolled will ever look at them; the autopatrol right).
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptMar 7 2017, 3:26 AM
Restricted Application added subscribers: TerraCodes, Aklapper. · View Herald Transcript

Need to investigate how this relates to patrol, and 'Review status'.

Mattflaschen-WMF renamed this task from Port FlaggedRevs to new RCFilters to Port FlaggedRevs to new RCFilters UI.Apr 14 2017, 12:10 AM
Zache added a subscriber: Zache.Apr 20 2017, 3:13 PM
Zache added a comment.EditedApr 20 2017, 3:40 PM

Fiwiki uses Flagged revs and there is also patrolling enabled for patrol flag support in API. Setup is that the autopatrollers are also autoreviewed and users in editor user group are also in patroller user group. (T144817)

Based on fiwiki:s experiences:

If something is manually reviewed with flagged revision it is also patrolled, if review is removed then patrol marks are removed and if multiple revisions are approved at same time then all revisions are patrolled too. It seems to be working as expected. In database level the data is stored correctly to the recentchanges table, but not to the logging table so there will be cases when you can't know why something is patrolled.

Also If something is manually patrolled then will doesn't become reviewed in flagged revs so there is no interaction in that direction. In fiwiki this is handled by bot which reviews patrolled edits.

Zache added a comment.Apr 20 2017, 3:48 PM

Flagged revs documentation: "$wgUseRCPatrol is enabled with the extension. Patrolling of reviewable pages is disabled, but flagged revisions are marked as patrolled in Recent Changes. This will mean that the only way to patrol a reviewable revision is to flag it. Non-reviewable pages still behave as normal (depending on site patrol settings)."

If user have autoreview user right for FlaggedRevs but not autopatrol for patrolling then his/her edits will be only autoreviewed for Flagged Revs. This is the case in the Portuguese Wikipedia where autoconfirmed users have autoreview and patrol user rights but they don't have autopatrol use right.

I like this idea. I need to hear a clear statement of the use case. What is the user trying to do?

My guess is that she wants to be able to find edits that have been nominated for review in order to review them. My guess is that Flagged Revs wants to be its own filter group.

it sounds like all reviewed edits are also patrolled. But what I don't understand are 1) whether "reviewed" is a separate piece of data that goes with the edit or not, and 2) whether the fact that an edit was nominated for review is a piece of data that stays with the edit. So, e.g., once an edit has been reviewed, is it still "flagged"? And are all edits that have been "reviewed" also "patrolled" (in which case finding for review status is redundant).

But, again, please describe what the situations and goals are liable to be of users who want/need this.

Without the RCFilters beta feature enabled, you'd see two separate filters, both "Hide patrolled edits" and "Hide reviewed edits". There is some overlap between those two. The simple thing to do here would be to just port "Hide reviewed edits" to a simple "Reviewed" / "Unreviewed" filter group (same as "Patrolled" / "Unpatrolled", which has already been ported), but we may want to consider if we should handle it differently because of the overlap that exists (it sounds to me like all reviewed edits are also patrolled, but some things can be patrolled without being reviewed?).

Zache added a comment.Apr 21 2017, 1:24 AM

@Catrope ''(it sounds to me like all reviewed edits are also patrolled, but some things can be patrolled without being reviewed?''

Yes, I think this is how it should be working.

However it doesn't mark automatically reviewed Flagged revs edits as patrolled in Portuguese Wikipedia. (See quarry: 18151) Now when i tested it locally it looks like that if $wgFlaggedRevsProtection = true it doesn't mark autoreviewed edits as patrolled and if $wgFlaggedRevsProtection = false it marks them. So this looks like bug in Flagged Revs protection mode.

Mattflaschen-WMF added a comment.EditedApr 21 2017, 4:30 PM

I like this idea. I need to hear a clear statement of the use case. What is the user trying to do?

IMHO, there are multiple use cases. They could be looking for edits that need to be reviewed, or hiding reviewed edits (the same way you would check everything except "Very likely good" or check only "Unpatrolled") to focus on more-likely-to-be-bad edits.

it sounds like all reviewed edits are also patrolled.

That would make sense, but not always: T150086: Don't autopatrol autoreviewed users in protection-based configs . This is intentional, not a bug. See that task. There are arguments given for why it should be that way.

But what I don't understand are 1) whether "reviewed" is a separate piece of data that goes with the edit or not,

Yes.

and 2) whether the fact that an edit was nominated for review is a piece of data that stays with the edit. So, e.g., once an edit has been reviewed, is it still "flagged"?

There are multiple modes of flagged revisions (it's very configurable), two of which seem relevant here:

  1. After the page is "pending changes protected" (a specific type of protection for this purpose), every edit to the page is unreviewed, and generally a stable reviewed version shows. In this case, it's not an edit that was "nominated for review".
  2. Deferred changes (code not merged yet), where a specific change is marked for review.

Either way, once the edit is reviewed, it's remembered that it needed review.

Stryn added a subscriber: Stryn.Apr 24 2017, 3:58 PM

Wikis that have both RC patrolling and FlaggedRevs (in some form) enabled:

alswiki
bnwiki
dewikiquote
dewiktionary
enwiktionary
fawiki
fawikinews
fiwiki
hiwiki
idwiki
ptwiki
ptwikibooks

@Catrope said in today's meeting we should start by just porting it over to the new UI. My understanding is this means defining its own group, very similar to patrol (but completely separate).

Catrope updated the task description. (Show Details)Apr 28 2017, 10:41 PM

@Catrope said in today's meeting we should start by just porting it over to the new UI. My understanding is this means defining its own group, very similar to patrol (but completely separate).

I've repurposed this task for that, and edited the task description to include my updated understanding of the interaction between review and patrol. If we want to try to come up with a nicer way to represent this than two separate filter groups, then I suggest that be made a separate task.

Catrope set the point value for this task to 8.Apr 28 2017, 10:57 PM

There was discussion at today's meeting about having patrol being a subset of reviewed edits.

We need to confirm:

  • Whether the initial implementation will try to use a single group (unifying patrol and review) (task says no currently).
  • If a single group, whether 'patrolled' is a strict subset of 'reviewed' (and if not, should we make it).

If it is a strict subset, I think we could do:

[ ] Reviewed edits
[ ] Patrolled edits
[ ] Neither reviewed nor patrolled

and use the subset support that already exists.

We don't need to offer all possibilities in the filters, but the possibilities we do offer should be accurate.

Mattflaschen-WMF added a comment.EditedMay 2 2017, 3:35 AM

Another thing to consider:

For a wiki with RC patrol, an edit (and even log entry) is either "already patrolled" or "needs to be patrolled".

That is not true for FlaggedRevs. A particular edit (in fact depending on the wiki, often most edits) can neither need review nor be reviewed (and will not be hidden by hideReviewed).

That also raises the question of whether we should have a filter to show only edits that need review (though there is at least one page for that, Special:PendingChanges).

Zache added a comment.May 2 2017, 2:30 PM

That also raises the question of whether we should have a filter to show only edits that need review

This would be nice. However biggest reason for this is that FR can be used for just in some namespaces so pending changes is different than all unreviewed changes which includes non flagged revision namespace edits too.

jmatazzoni updated the task description. (Show Details)May 3 2017, 9:16 PM

I've written up the Flagged Revisions filter spec and put it in the Description, above. Please have a look see.

jmatazzoni renamed this task from Port FlaggedRevs to new RCFilters UI to Create new RC Filters group for 'Flagged Revisions', based on the old 'Hide reviewed edits' function.May 3 2017, 9:19 PM
jmatazzoni updated the task description. (Show Details)May 3 2017, 9:23 PM

Replying to @Etonkovidova's question at T172451:

Note: 'Hide patrolled edits from recent changes' in cawiki is different from plwiki 'Hide reviewed edits' ?

Yes, despite sounding similar, they're quite different. Basically, all edits are live to everyone, whether they've been patrolled or not. Except... on pages using Flagged Revisions, unreviewed edits may not display by default (e.g. to readers).

We have two users from uk.wp who complain (here and here) because of the too important blank space taken by the "Hide reviewed edits" on their wiki.
Fixing those configurations based on particular extensions would be very much appreciated before we release the filters by default.

New request to have it integrated, from ar.wp.

@Catrope can you generate a list of the wikis that this ticket will help? Or, put a different way, the wikis we will consider holding back until this is fixed? Please comment on whether you think that's a good idea.

Zache added a comment.EditedFri, Sep 22, 4:15 AM

Fix for the empty space could be floating the remaining rcfilters in fieldset box to the right side of the screen so it would be leveled at the same level than the new recent changes box.

There is still empty space but when the page is loaded it is inside of min-height of the whole new filter box so it is not related to the rcfilters fieldset.

CSS rule

mw-rcfilters-ui-FormWrapperWidget {
	float:right;
	margin:0 ;
	padding:0.5em ;
}

And example pic of the result