laaknor-wmfbugzilla wrote:

I would like to support this and upgrade it's status to "high", as this would save local sysops/patrollers a lot of time with new users not aware of "preview"

michael.frey wrote:

Maybe an idea to simplify the implementation:
When a edit is reverted, then are the flags (the ! in the Recent Changes) reverted edits cleared, that mean they are shown like patrolled.
Disadvantage of this solution is, that there isn't a log entry, but I think that the code of revert could be a basic to work on.

Wiki.Melancholie wrote:

*** Bug 12573 has been marked as a duplicate of this bug. ***

Wiki.Melancholie wrote:

Note: By a rollback all revisions in between get auto-patrolled, so a function for this actually exists; just a link is missing.

Sebastian.Dietrich wrote:

Would be a great improvement - would reduce around 50% of my patrolling time...

mike.lifeguard+bugs wrote:

Doesn't block bug 9768, as it's fixed. Blocking bug 12641 seems dubious to me as well.

(In reply to comment #4)

Note: By a rollback all revisions in between get auto-patrolled, so a function
for this actually exists; just a link is missing.

A rollback auto-patrols every revision, but a rollback is possible only to revert edits by a single author: that's great, but it would be useful to patrol even revisions by different authors (since the multiple diff lets us know if they're fixed yet).
Actually, a rollback auto-patrols only the last edit (the revision added by the rollbacker), if you look at the logs, even if then the rollbacked revisions are considered patrolled. Thus, perhaps not only a link is needed.

• Bug 20060 has been marked as a duplicate of this bug. ***

svippy wrote:

(In reply to comment #4)

Note: By a rollback all revisions in between get auto-patrolled, so a function
for this actually exists; just a link is missing.

Not all patrolling is removing content. So, no, there is no such function.

I'd even recommend it to patrol even if some of the changes in the bunch are already patrolled (e.g. sysop edits) and obviously by any author.

chstole wrote:

No progress yet? If it could speed up the process somewhat; let it at first only work with the edits of one user, just like the rollback function. Most of the time, to my own experience at least (on a small wiki), that would be enough.

• Bug 42414 has been marked as a duplicate of this bug. ***

This is made higher priority by the workaround [[m:User:Pathoschild/Scripts/Ajax_sysop]] being broken: https://github.com/Pathoschild/Wikimedia-contrib/issues/8
en.voy would like it too, it seems. http://lists.wikimedia.org/pipermail/wikivoyage-l/2013-January/000354.html

I thought about implementing this but I'm struggling a bit...
Is there any reason at all to have older RC entries unpatrolled while newer ones are already patrolled?
Do we need a log entry for every revision that is patrolled? (This could flood the logs a LOT).

If the answer to the first question is "No" then the answer to the second one would IMO be that a single log entry is enough (as it's clear that this includes ALL older revisions)...

(In reply to comment #13)

I thought about implementing this but I'm struggling a bit...
Is there any reason at all to have older RC entries unpatrolled while newer
ones are already patrolled?

Yes but only if one nitpicks a lot: strictly speaking you've not reviewed all edits but only a collation of them, however if you are looking at that specific multi-revisions diff it probably means it's a single edit in multiple steps (which can be patrolled only if from same author and with rollback), or some other sort of related diffs you're checking together and acting upon as a consequence (if you come from enhanced RC, they must be in the same solar day).

Do we need a log entry for every revision that is patrolled? (This could
flood
the logs a LOT).

I don't think it would flood logs a lot, because it's merely what we're already doing now (especially with AJAX patrolling), just with less clicks. And patrol log entries are hidden by default.
Either way, it doesn't matter much IMHO.

(In reply to comment #14)

Yes but only if one nitpicks a lot: strictly speaking you've not reviewed all
edits but only a collation of them, however if you are looking at that
specific
multi-revisions diff it probably means it's a single edit in multiple steps
(which can be patrolled only if from same author and with rollback), or some
other sort of related diffs you're checking together and acting upon as a
consequence (if you come from enhanced RC, they must be in the same solar
day).

In case we only want this for either the same day or even better the same user this is feasible. If you want it for all revision covered by the current diff thinks are going to get a lot more complicated as the recentchanges table lacks usable indexes here and there are pages with a LOT of revision in the RC life span ( eg. https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents )

Do we need a log entry for every revision that is patrolled? (This could
flood
the logs a LOT).

I don't think it would flood logs a lot, because it's merely what we're
already
doing now (especially with AJAX patrolling), just with less clicks. And
patrol
log entries are hidden by default.
Either way, it doesn't matter much IMHO.

(Per above) If that only covers several edits by one user it's probably fine but if it covers the whole RC lifespan this could grow up to several thousand changes which in turn would mean several thousand log entries (which is insane for various reasons).

(In reply to comment #15)

(Per above) If that only covers several edits by one user it's probably fine
but if it covers the whole RC lifespan this could grow up to several thousand
changes which in turn would mean several thousand log entries (which is
insane
for various reasons).

It would be fair, I think, to allow multi-diff patrols e.g. only when opened with a parameter similar to rcid, which would be provided on RC/WL only; it's what most comments ask.
Then the issue of making it always available would be split to another bug similar to bug 15936, to be worked on after evaluating performance and community effects of this first implementation, and how big the need for it is.

(In reply to comment #16)

It would be fair, I think, to allow multi-diff patrols e.g. only when opened
with a parameter similar to rcid, which would be provided on RC/WL only; it's
what most comments ask.
Then the issue of making it always available would be split to another bug
similar to bug 15936, to be worked on after evaluating performance and
community effects of this first implementation, and how big the need for it
is.

The rcid parameters we're currently using are there for performance reasons (and I'm on getting rid of them). So I would like to either do this right (no parameter) or not (a parameter couldn't increase the performance here anyway as we would need to know a lot of rcids).

The best way I currently see is to have it patrol all changes by a user in a row (that's feasible on the MediaWiki side and shouldn't be overly controversial on the community side).

(In reply to comment #17)

The best way I currently see is to have it patrol all changes by a user in a
row (that's feasible on the MediaWiki side and shouldn't be overly
controversial on the community side).

That would surely be a very nice first step but wouldn't be enough to close this bug. At least the diff links provided by the interface itself in enhanced RC should be patrollable, this bug asks. Anyway, one step at a time is a wise way to proceed.

What's the relation of this to hoo's recent patrolling changes? (I1e24733c)

(In reply to comment #19)

What's the relation of this to hoo's recent patrolling changes? (I1e24733c)

See bug 43977 comment 21; this part may have been removed completely though, or rather left to a following step, because I don't see anything to patrol multiple edits, even very recent, nor coming from history nor from RC.

• Bug 43977 has been marked as a duplicate of this bug. ***

This open task still causes a lot of unproductive extra work falling entirely in the shoulders of experienced editors. Maybe we can push it to the Community-Tech backlog?

In T10697#133638, @Nemo_bis wrote:

(In reply to comment #13)

Is there any reason at all to have older RC entries unpatrolled while newer
ones are already patrolled?

Yes but only if one nitpicks a lot.

What if we don't nitpick a lot and bet for the simpler solution (patrolling one edit marks all the previous edits patrolled as well)?

The social goal of patrolling is to assure that changes in content are OK. If an editor marks as patrolled the last version of a page, it is assumed that the page is OK. Therefore, all the previous non-patrolled edits could be marked as patrolled automatically, and people's watchlists and the list of recent changes would point to pages that still nobody has patrolled.

Currently, it still happens too often that only the last edit is patrolled, creating extra work either for the same editor (who may or may not bother about patrolling previous edits) or other editors (who get tired of seeing that the page is actually ok and checked by someone else, but the "cleaning" of older non-patrolled edits still needs to be done).

I disagree about "patrolling one edit marks all the previous edits patrolled as well". Sometimes previous editions need patrolling while last one doesn't - sometimes due to bad faith, sometimes due to lack of skill for certain actions.

Patrolling several edits of the same user should be possible, but only when seeing at last the global diff.

In T10697#1506087, @QuimGil wrote:

What if we don't nitpick a lot and bet for the simpler solution (patrolling one edit marks all the previous edits patrolled as well)?

Please don't. Otherwise I'll just have to stop patrolling good edits which happens after edits I'm not sure if are good or bad.

If an editor marks as patrolled the last version of a page, it is assumed that the page is OK.

That is not the case. That is FlaggedRevs, not patrolling.

Ok ok, it was just an idea for a simpler solution. One click for multi-edit span diff is the superior solution.

Do you think the UI would need any changes or would the current "Mark as patrolled" in a multi-edit diff be enough to mark each edit within that diff patrolled?

(Just one note, "patrolling" means just that, patrolling. It is not an evaluation on whether an edit is good or bad. It means that someone trusted look at it and either saw it was OK or took an action.)

I think it is enough, but the text could be changed to something in the lines of

• "Mark X intermediate revisions by Y users as patrolled" or
• "Mark X revisions as patrolled"

Change 230818 had a related patch set uploaded (by Ricordisamoa):
[WIP] "Mark all as patrolled" link for multi-edit diffs

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

Seen now:

"When an assignee is already set for a task, its priority should not be changed without agreement of the assignee or development team first."

So? Do you have objections?

T61609 is surfacing threateningly