Hi everyone,
A few of us (Brandon, Alolita, and I) had a conversation about clearing up the more vague items on the Pending Changes roadmap (http://www.mediawiki.org/wiki/Pending_Changes_enwiki_trial/Roadmap ), and we'd like to get some further feedback on what we discussed.
First, the priority that we're tackling the vague stuff: 1. 25299: Make pending revision status clearer when viewing page: https://bugzilla.wikimedia.org/show_bug.cgi?id=25299 2. 25295: Improve reviewer experience when multiple simultaneous users review Pending Changes https://bugzilla.wikimedia.org/show_bug.cgi?id=25295 3. 25296: History style cleanup - investigate possible fixes and detail the fixes https://bugzilla.wikimedia.org/show_bug.cgi?id=25296 4. 25301: Firm up the list of minor UI improvements for the November 2010 Pending Changes release https://bugzilla.wikimedia.org/show_bug.cgi?id=25301 5. 25298: Figure out what (if any) new Pending Changes links there should be in the side bar https://bugzilla.wikimedia.org/show_bug.cgi?id=25298
(Note that there are other tasks that Chad and Priyanka are already tackling that aren't on this list.)
Now for some more detail on each: ================================================ 1. 25299: Make pending revision status clearer when viewing page: https://bugzilla.wikimedia.org/show_bug.cgi?id=25299
Right now, it takes a sharp eye to notice when one is looking at a page that hasn't been accepted yet. The main visual indicators are an icon on the right, and the fact that the "Pending Changes" rather than the "Read" tab is highlighted. What we plan to do here will be modeled on what you see when you're looking at an old revision (i.e. there will be a horizontal notice at the top indicating "This is an pending revision of this page, as edited by 127.0.0.1 (talk | contribs) at 13:37, 7 October 2010. It may differ significantly from the accepted revision.")
An old decision that we plan to revisit: currently, the revision you are shown depends on whether you're logged in or not you are logged in. If you're not logged in, then by default, you see the accepted revision. If you are logged in, you see the pending revision by default. Brandon feels pretty strongly that we need to be much more consistant here, always showing the accepted revision regardless of logged-in status. There's some research we need to do to make sure we understand the current rationale, but barring any unexpected insight, we'll probably be making the switch.
================================================ 2. 25295: Improve reviewer experience when multiple simultaneous users review Pending Changes https://bugzilla.wikimedia.org/show_bug.cgi?id=25295
Here are some of Brandon's initial thoughts. * We only want to show that a page is "under review" to other reviewers of the page. * We want to show who is reviewing the page, but also only to other reviewers of the page. * We should include better colors/icon.
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".
================================================ 3. 25296: History style cleanup - investigate possible fixes and detail the fixes https://bugzilla.wikimedia.org/show_bug.cgi?id=25296
This one represents a bit of a paradox for us. On one hand, we know that there is a LOT of work to do here, and thus, we know that we're not going to make significant usability progress on this one by November. On the other hand, there are a number of little things that are annoyingly wrong, and with just a small amount of care and attention, we could make incremental progress on.
We don't want to allow the perfect to be the enemy of the good, so we're going to try to restrain ourselves, and come up with a few easy things that we can do to make this a little bit better. Brandon is planning to spend some time looking at the history page and come up with some formatting and wording fixes that will make the Pending Changes history pages a little better.
================================================ 4. 25301: Firm up the list of minor UI improvements for the November 2010 Pending Changes release https://bugzilla.wikimedia.org/show_bug.cgi?id=25301
This is actually a task for sorting through a small list of seemingly easy things. Many of the items here are probably within the grasp of an interested admin to just fix rather than waiting on us for.
Brandon is planning to sweep through on all of these and come up with a few specific recommendations. If you have some thoughts, we'd appreciate them here.
------------------------ 4a. Better links to documentation on PC related specialpages - from the comments: "The review page could have links to Help documentation, reviewer guidelines, and PC policy pages."
------------------------ 4b. Incorporate the PC protection rationale (protection log message) into the review screen as instruction to the reviewer - from the comments: "Make the protection rationale visible (currently it's click-to-expand). That way Reviewers could see up front if PC was in use for Vandalism, BLP, edit warring, etc. Helps alert them to the 'type' of problematic edits, particularly more subtle kinds."
------------------------ 4c. Add short reviewer instructions to the review page - from the comments: " Just a summary of how to review. Depends on policy discussions about reverting vandalism or also poor edits. Currently could just include the reviewer guidelines writ small.
------------------------ 4d. Quick link to Pending Changes specialpages - from the comments: "Easy access from the sidebar, or other common locations (not sure where)."
================================================ 5. 25298: Figure out what (if any) new Pending Changes links there should be in the side bar https://bugzilla.wikimedia.org/show_bug.cgi?id=25298
We're probably not going to address this one in the November 2010 release. If we do it, we need to make it conditional upon whether the person has reviewer rights. The problem with this one is that we don't yet have clear guidelines for what belongs in the toolbox on the left, and whether any of the pending changes special pages rise to the level of importance that we should put them in the toolbox. ================================================ That's the list that we're looking at now. Let us know what you think.
Rob