Last modified: 2010-07-07 20:48:41 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T25987, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 23987 - For pending changes, the reject option must be suppressed if there are edits by multiple authors
For pending changes, the reject option must be suppressed if there are edits ...
Status: RESOLVED INVALID
Product: MediaWiki extensions
Classification: Unclassified
FlaggedRevs (Other open bugs)
unspecified
All All
: High enhancement (vote)
: ---
Assigned To: Aaron Schulz
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-16 03:32 UTC by Gregory Maxwell
Modified: 2010-07-07 20:48 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Gregory Maxwell 2010-06-16 03:32:40 UTC
Copying my post to wikien-l,wikitech-l:


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.
Comment 1 Gregory Maxwell 2010-06-16 03:33:30 UTC
http://lists.wikimedia.org/pipermail/wikitech-l/2010-June/048130.html  (in case there is further discussion there)
Comment 2 Aaron Schulz 2010-06-16 03:51:52 UTC
There is no reject button. Are you talking about the item that howie wanted but does not exist yet?
Comment 3 Aaron Schulz 2010-06-16 04:01:29 UTC
Considering this a specification bug for the proposed "reject" button feature.
Comment 4 Aaron Schulz 2010-06-16 04:03:19 UTC
(In reply to comment #3)
> Considering this a specification bug for the proposed "reject" button feature.

See http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Reject_Pending_Revision
Comment 5 Aaron Schulz 2010-06-16 05:06:07 UTC
Still, one could think of the case with:
accepted edit A, good edit B, vandalism C (which also reverted B), edit D (which removed the vandalism part of B and fixed a typo).

The pending changes diff just shows a typo correction, and the reviewer would accept.
Comment 6 Aaron Schulz 2010-06-16 05:15:04 UTC
See also bug 22846. Maybe collapsible history excerpts or something would help.
Comment 7 Aaron Schulz 2010-06-17 00:48:46 UTC
Given #5, why is REJECT worse than ACCEPT?
Comment 8 CBM 2010-06-17 01:08:04 UTC
It seems like it isn't. Why do we need links to review pages from the list of pages? It seems like that only encourages hasty reviewing.  If there is more than one author among the unreviewed revisions, just giving a link to the page history seems reasonable.
Comment 9 Aaron Schulz 2010-06-19 04:02:50 UTC
(In reply to comment #7)
> Given #5, why is REJECT worse than ACCEPT?

It is a good reason to avoid language like "rejected 4 edits" in any REJECT auto-summary though.
Comment 10 Rob Lanphier (RobLa) 2010-07-07 20:48:41 UTC
We plan to take this into account (sorry for the "invalid" resolution...there wasn't anything more appropriate.  We need an "under advisement" state)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links