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