Imagine an article with many revisions and pending changes enabled: A, B, C, D, E, F, G...
A is an approved edit. B,C,D,E,F,G are all pending edits.
B is horrible vandalism that the subsequent edits did not fix.
You are a reviewer, you go to review page by clicking a pending review link. On the review page you can accept— thus putting the horrible vandalism on the site. Or you can "reject" which throws out the all the good edits of C,D,E,F,G by reverting it to A.
To quote someone from IRC: "this seems like its going to make vandals even more effective because all they have to do is make one edit in a string of ten good ones, and then the entire set has to be thrown out"
But that isn't true at all. You're not confined to the review page, you simply go to the edit history, click undo on B, and then approve your own edit (it won't be auto-approved because G wasn't approved). Tada.
This completely non-obvious to people, because the only options on the review page are accept or reject, and it's already causing confusion. This is a direct result of the late in the process addition of the review button, — trying to fit the round-peg of a revision reviewing system (which we can't have because of the fundamental incompatibility with single linear editing history) in to presentation-flagging system square hole that we actually have.
I don't know how to fix this. We could remove the reject button to make it more clear that you use the normal editing functions (with their full power) to reject. But I must admit that the easy rollback button is handy there. Alternatively we could put a small chunk of the edit history on the review page, showing the individual edits which comprise the span-diff (bonus points for color-coding if someone wants to make a real programming project out of it) along with the undo links and such.
In the meantime I expect enwp will edit the message text to direct people to the history page for more sophisticated editing activities.
(Thanks to Risker for pointing out how surprising the pending review page was for this activity)
On Tue, Jun 15, 2010 at 11:05 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
Imagine an article with many revisions and pending changes enabled: A, B, C, D, E, F, G...
[snip]
I don't know how to fix this. We could remove the reject button to make it more clear that you use the normal editing functions (with their full power) to reject. But I must admit that the easy rollback button is handy there. Alternatively we could put a small chunk of the edit history on the review page, showing the individual edits which comprise the span-diff (bonus points for color-coding if someone wants to make a real programming project out of it) along with the undo links and such.
[snip]
Further discussion with Risker has caused me to realize that there is another significant problem situation with the reject button.
Consider the following edit sequence:
A, B, C, D, E
A is a previously approved version. B, and D are all excellent edits. C and E are obvious vandalism. E even managed to undo all the good changes of B,D while adding the vandalism.
A reviewer hits the pending revisions link in order to review, they get the span diff from A to E. All they see is vandalism, there is no indication of the redeeming edits in the intervening span. So they hit reject. The good edits are lost.
Unlike the prior problem, the only way to solve this would be only display the REJECT button if all of the pending changes are by the same author (or limiting it to only one pending change in the span, which would be slightly more conservative but considering the behaviour of the rollback button I think the group-by-author behaviour would be fine). The accept button is still safe.
As I understand it, and apologies if mistaken, all of this is based on a misunderstanding of the tool.
A reviewer faced with any mix of edits and wishing to "do something" (ie not ignore it all) has two main choices.
They can accept the most recent edit, or they can add an edit of their own (which could be a revert or a "fix" of problem edits).
In either case, the latest edit is presumed good quality (because they are doing it) and it becomes "accepted".
The misunderstanding, as I understand it, is that pending changes doesn't care about any intervening edits or unchecked page history. If there had been 1000 edits since the last accepted revision, or 30 but all vandalism, none of that matters. The aim of the tool is to ensure the public (ie /latest/) version is presentable. It doesn't care for or censor historic revisions. Once a revision is no longer current, then whether it was accepted, reverted, unchecked or the like in the past is immaterial. The vandalism and good edits remain in the page history as normal, users can see them, revert them, sort out complex mixes of vandalism/non-vandalism as much as they like. Past "good" edits are no more "lost" than they ever were. The purpose of pending changes is to ensure the current presented version will be presentable to non-editors and logged-out users - nothing more.
FT2
On Wed, Jun 16, 2010 at 4:30 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Tue, Jun 15, 2010 at 11:05 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
Imagine an article with many revisions and pending changes enabled: A, B, C, D, E, F, G...
[snip]
I don't know how to fix this. We could remove the reject button to make it more clear that you use the normal editing functions (with their full power) to reject. But I must admit that the easy rollback button is handy there. Alternatively we could put a small chunk of the edit history on the review page, showing the individual edits which comprise the span-diff (bonus points for color-coding if someone wants to make a real programming project out of it) along with the undo links and such.
[snip]
Further discussion with Risker has caused me to realize that there is another significant problem situation with the reject button.
Consider the following edit sequence:
A, B, C, D, E
A is a previously approved version. B, and D are all excellent edits. C and E are obvious vandalism. E even managed to undo all the good changes of B,D while adding the vandalism.
A reviewer hits the pending revisions link in order to review, they get the span diff from A to E. All they see is vandalism, there is no indication of the redeeming edits in the intervening span. So they hit reject. The good edits are lost.
Unlike the prior problem, the only way to solve this would be only display the REJECT button if all of the pending changes are by the same author (or limiting it to only one pending change in the span, which would be slightly more conservative but considering the behaviour of the rollback button I think the group-by-author behaviour would be fine). The accept button is still safe.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
The crux of this issue is that to revert individual edits one has to go to the page history, the pending changes review window does not permit this.
Gmaxwell and I have worked out a step-by-step process for even the least technical reviewer to follow. You can find it here: http://en.wikipedia.org/wiki/Wikipedia_talk:Reviewing#Step-by-step_.22how-to...
Best,
Risker/Anne
On 16 June 2010 00:25, FT2 ft2.wiki@gmail.com wrote:
As I understand it, and apologies if mistaken, all of this is based on a misunderstanding of the tool.
A reviewer faced with any mix of edits and wishing to "do something" (ie not ignore it all) has two main choices.
They can accept the most recent edit, or they can add an edit of their own (which could be a revert or a "fix" of problem edits).
In either case, the latest edit is presumed good quality (because they are doing it) and it becomes "accepted".
The misunderstanding, as I understand it, is that pending changes doesn't care about any intervening edits or unchecked page history. If there had been 1000 edits since the last accepted revision, or 30 but all vandalism, none of that matters. The aim of the tool is to ensure the public (ie /latest/) version is presentable. It doesn't care for or censor historic revisions. Once a revision is no longer current, then whether it was accepted, reverted, unchecked or the like in the past is immaterial. The vandalism and good edits remain in the page history as normal, users can see them, revert them, sort out complex mixes of vandalism/non-vandalism as much as they like. Past "good" edits are no more "lost" than they ever were. The purpose of pending changes is to ensure the current presented version will be presentable to non-editors and logged-out users - nothing more.
FT2
On Wed, Jun 16, 2010 at 4:30 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Tue, Jun 15, 2010 at 11:05 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
Imagine an article with many revisions and pending changes enabled: A, B, C, D, E, F, G...
[snip]
I don't know how to fix this. We could remove the reject button to make it more clear that you use the normal editing functions (with their full power) to reject. But I must admit that the easy rollback button is handy there. Alternatively we could put a small chunk of the edit history on the review page, showing the individual edits which comprise the span-diff (bonus points for color-coding if someone wants to make a real programming project out of it) along with the undo links and such.
[snip]
Further discussion with Risker has caused me to realize that there is another significant problem situation with the reject button.
Consider the following edit sequence:
A, B, C, D, E
A is a previously approved version. B, and D are all excellent edits. C and E are obvious vandalism. E even managed to undo all the good changes of B,D while adding the vandalism.
A reviewer hits the pending revisions link in order to review, they get the span diff from A to E. All they see is vandalism, there is no indication of the redeeming edits in the intervening span. So they hit reject. The good edits are lost.
Unlike the prior problem, the only way to solve this would be only display the REJECT button if all of the pending changes are by the same author (or limiting it to only one pending change in the span, which would be slightly more conservative but considering the behaviour of the rollback button I think the group-by-author behaviour would be fine). The accept button is still safe.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On Wed, Jun 16, 2010 at 12:25 AM, FT2 ft2.wiki@gmail.com wrote:
Once a revision is no longer current, then whether it was accepted, reverted, unchecked or the like in the past is immaterial.
This is not quite true. If a revision is marked as reviewed, and a reviewer later reverts the article back to that revision, the revert will automatically be marked as reviewed. For this reason, it's important not to mark any revision with vandalism as 'reviewed', even if you immediately fix the vandalism afterwards.
I made an example of this at [[Wikipedia:Pending changes/Testing/CBM]]. I used an alternate account CBM2 to make bad edits, and used my admin account CBM to review them and remove the bad ones. I intentionally made a mistake at timestamp 3:06 by accepting a revision with vandalism and then undoing the vandalism separately.
But later, I looked at this diff
http://en.wikipedia.org/w/index.php?title=Wikipedia%3APending_changes%2FTest...
and clicked "undo" because it looked safe.
Looking at that diff, wouldn't you do the same thing? Because the vandalism was present in both of the versions being compared, the diff didn't show it. But because the original revision was marked as reviewed, the new version was also marked as reviewed.
The moral is you should try not to accept edits with vandalism in them, under the assumption that any version you review might later become the live version.
- Carl
Updated at:
http://en.wikipedia.org/wiki/Help:Pending_changes#How_it_affects_past_revisi...
FT2
On Wed, Jun 16, 2010 at 11:29 AM, Carl (CBM) cbm.wikipedia@gmail.comwrote:
On Wed, Jun 16, 2010 at 12:25 AM, FT2 ft2.wiki@gmail.com wrote:
Once a revision is no longer current, then whether it was accepted, reverted, unchecked or the like in the past is immaterial.
This is not quite true. If a revision is marked as reviewed, and a reviewer later reverts the article back to that revision, the revert will automatically be marked as reviewed. For this reason, it's important not to mark any revision with vandalism as 'reviewed', even if you immediately fix the vandalism afterwards.
I made an example of this at [[Wikipedia:Pending changes/Testing/CBM]]. I used an alternate account CBM2 to make bad edits, and used my admin account CBM to review them and remove the bad ones. I intentionally made a mistake at timestamp 3:06 by accepting a revision with vandalism and then undoing the vandalism separately.
But later, I looked at this diff
http://en.wikipedia.org/w/index.php?title=Wikipedia%3APending_changes%2FTest...
and clicked "undo" because it looked safe.
Looking at that diff, wouldn't you do the same thing? Because the vandalism was present in both of the versions being compared, the diff didn't show it. But because the original revision was marked as reviewed, the new version was also marked as reviewed.
The moral is you should try not to accept edits with vandalism in them, under the assumption that any version you review might later become the live version.
- Carl
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l