Page MenuHomePhabricator

Implement button for marking all N changes as patrolled in a multi-edit span diff
Open, NormalPublic

Tokens
"Love" token, awarded by Liuxinyu970226."Love" token, awarded by Tractopelle-jaune."Orange Medal" token, awarded by Krinkle."Doubloon" token, awarded by Nemo_bis."Like" token, awarded by matej_suchanek."Doubloon" token, awarded by Ricordisamoa."Like" token, awarded by QuimGil."Love" token, awarded by He7d3r.
Assigned To
Authored By
bzimport, Jan 19 2007

Description

Author: stanley

Description:
In enhanced recent changes diff page, the diff is cumulated, so instead of marking the changes as patrolled one by one per revision, it would be better if we can marking those changes altogether. Please provide link to "mark these n changes as patrolled" in the cumulated diff page.

On the value of working on this feature request: T17936 tripled the number of patrollers on the English Wikipedia and this feature may achieve similar impact; patrol is way more used than the PageTriage extension on the English Wikipedia; patrol is used on thousands of wikis; PageTriage had 2 devs and a team of 7 working for some 6 months. Assuming PageTriage was worth what it cost, then fixing this feature is likely to be worth several hundreds thousands dollars.


See Also:

Details

Reference
bz8697

Event Timeline

bzimport raised the priority of this task from to High.
bzimport set Reference to bz8697.
bzimport added a subscriber: Unknown Object (MLST).

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.

demon added a comment.Aug 15 2009, 5:51 PM
  • 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

hoo added a comment.Jan 15 2013, 11:29 PM

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.

hoo added a comment.Jan 15 2013, 11:56 PM

(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.

hoo added a comment.Jan 16 2013, 8:53 AM

(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.

hoo added a comment.Nov 23 2013, 6:55 PM
  • Bug 43977 has been marked as a duplicate of this bug. ***
mxn added a subscriber: mxn.Nov 24 2014, 8:53 PM
Krinkle updated the task description. (Show Details)Jan 9 2015, 3:11 AM
Krinkle lowered the priority of this task from High to Low.
Krinkle set Security to None.
Krinkle removed a subscriber: Unknown Object (MLST).
Nemo_bis raised the priority of this task from Low to Normal.Jan 9 2015, 9:36 PM

Considering developer time was spent on developing an entire extension (PageTriage) for patrolling, yet simply fixing the "don't require rcid parameter" bug had three times as big an impact on statistics, I question the idea that this feature request isn't worth the (limited) developer time needed.

Tacsipacsi updated the task description. (Show Details)Apr 7 2015, 2:51 PM
He7d3r updated the task description. (Show Details)Apr 7 2015, 5:28 PM
matmarex removed a subscriber: matmarex.Apr 7 2015, 5:37 PM
QuimGil added a subscriber: QuimGil.

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 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).

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 4 2015, 12:31 PM

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.

He7d3r added a comment.Aug 4 2015, 1:09 PM

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.

QuimGil added a comment.EditedAug 4 2015, 2:00 PM

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.)

He7d3r added a comment.Aug 4 2015, 2:44 PM

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

Nemo_bis raised the priority of this task from Normal to High.Sep 5 2015, 9:17 AM

Raising priority as it's being worked on.

Ricordisamoa lowered the priority of this task from High to Normal.Sep 5 2015, 9:22 AM

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

Nemo_bis updated the task description. (Show Details)Sep 5 2015, 9:27 AM
Nemo_bis raised the priority of this task from Normal to High.

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

Meno25 removed a subscriber: Meno25.Feb 22 2016, 6:23 PM
Ricordisamoa lowered the priority of this task from High to Normal.May 5 2016, 2:41 PM

Back to actual priority

Nemo_bis rescinded a token.Jul 16 2016, 8:00 AM
Nemo_bis awarded a token.
Bennylin removed a subscriber: Bennylin.Nov 20 2017, 1:45 AM
Krinkle removed a subscriber: Krinkle.