Last modified: 2011-10-07 01:47:07 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 T27295, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 25295 - Improve reviewer experience when multiple users simultaneously review Pending Changes
Improve reviewer experience when multiple users simultaneously review Pending...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
FlaggedRevs (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 24043
Blocks: 26335
  Show dependency treegraph
 
Reported: 2010-09-25 00:31 UTC by Rob Lanphier
Modified: 2011-10-07 01:47 UTC (History)
4 users (show)

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


Attachments

Description Rob Lanphier 2010-09-25 00:31:54 UTC
When multiple users review the same article at the same time (as frequently occurs), there are a number of things that can be frustrating:
*  One person accepts the changes hastily, while another is still carefully reading
*  An article can be advertised as "under review" merely because the reviewer is looking at the "review" link

More info can be found here (under "Review conflict"):
http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback/Archive_4#Succinct_yet_descriptive_list_of_issues_and_suggestions
Comment 1 Rob Lanphier 2010-09-28 01:25:01 UTC
Adding Brandon to the cc line.
Comment 2 Rob Lanphier 2010-10-08 03:23:56 UTC
Quoting the relevant portion of this email:
http://lists.wikimedia.org/pipermail/wikitech-l/2010-October/049813.html

Almost everyone who I've talked to about this problem feels like maybe
the timeout needs to be tuned, but since almost no one knows what the
timeout is, that may be the problem itself.

One possible workflow (inspired by our conversation, but not vetted by
Brandon or Alolita) is this:
*  On the list of pages to review, keep the "under review" notice
pretty much exactly as is
*  On the review page, in the "Review this revision" box, put one of
two notices:
**  "This page is being reviewed by User:Xyz, who started 20:09, 7 October 2010"
**  "You are being advertised as currently reviewing of this page
(started 20:09, 7 October 2010).  [Stop reviewing]"

This would add some transparency to the review process, which will
help us tune the timeout and generally make this work more as people
would expect it to.

Some implementation questions that we didn't know the answers to:
1) Do we know *who* is doing the reviewing of a page?  (i.e. is this
already stored somewhere we can get at it easily)  If so, the notice
should be pretty straightforward.
2) If so, when *anyone* looks at a set of pending changes, does it
mark it as "under review"?  We're assuming not, but one thing that's
frustrating is that any time a reviewer looks at a diff, that
automatically puts the page "under review".
Comment 3 Rob Lanphier 2010-10-18 20:46:12 UTC
One case where things seem to go sideways:
https://bugzilla.wikimedia.org/show_bug.cgi?id=24043
Comment 4 Aaron Schulz 2010-12-20 21:56:03 UTC
1) We don't know who is reviewing it.
2) It marks the page under review if any Reviewer looks at it now, atm.

I suppose a new table will be needed with oldid,newid,userid,exptime columns.
Comment 5 Aaron Schulz 2011-03-20 14:44:31 UTC
Tracking of user/startime and review form notices added in r84383. This still uses memcached for performance and only one person can be marked as reviewing something.
Comment 6 Aaron Schulz 2011-03-23 18:41:02 UTC
(In reply to comment #2)
> *  On the review page, in the "Review this revision" box, put one of
> two notices:
> **  "This page is being reviewed by User:Xyz, who started 20:09, 7 October
> 2010"
> **  "You are being advertised as currently reviewing of this page
> (started 20:09, 7 October 2010).  [Stop reviewing]"
> 

How would [stop reviewing] work? AJAX? Would it act as a back button or just leave the user there?
Comment 7 Krinkle 2011-04-17 19:11:30 UTC
Perhaps we can broaded the scope of this bug to the MediaWiki component.

A mediawiki core table for 'activity' usable by core and extensions as well.


Could by used by other stuff as well such as:
* http://www.mediawiki.org/wiki/Extension:EditWarning  / http://www.mediawiki.org/wiki/Extension:Ajax_Show_Editors
Comment 8 Aaron Schulz 2011-04-17 19:18:51 UTC
(In reply to comment #7)
> Perhaps we can broaded the scope of this bug to the MediaWiki component.
> 
> A mediawiki core table for 'activity' usable by core and extensions as well.
> 
> 
> Could by used by other stuff as well such as:
> * http://www.mediawiki.org/wiki/Extension:EditWarning  /
> http://www.mediawiki.org/wiki/Extension:Ajax_Show_Editors

I'd have a branch with an activity table but shelved it since I wasn't sure about hitting the master for this kind of stuff.
Comment 9 Aaron Schulz 2011-06-14 00:41:43 UTC
(In reply to comment #5)
> Tracking of user/startime and review form notices added in r84383. This still
> uses memcached for performance and only one person can be marked as reviewing
> something.

To be clear, the "This page is being reviewed" message is there, but not the "You are being advertised" one yet.
Comment 10 Aaron Schulz 2011-06-14 03:44:59 UTC
(In reply to comment #9)
> (In reply to comment #5)
> > Tracking of user/startime and review form notices added in r84383. This still
> > uses memcached for performance and only one person can be marked as reviewing
> > something.
> 
> To be clear, the "This page is being reviewed" message is there, but not the
> "You are being advertised" one yet.

Added in r90033.

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


Navigation
Links