Pending Changes enwiki trial/Roadmap

As part of wrapup of the Pending Changes enwiki trial, Jimmy Wales announced that he was asking the Wikimedia Foundation to keep the Pending Changes enabled. After further discussion, he asked the Wikimedia Foundation to come up with a schedule for "v2.0" of Pending Changes. While there may never be a single feature rollout that constitutes "v2", this page is intended to collect the most important features to have implemented prior to another English Wikipedia community discussion.

Please direct comments to the discussion page.

Items to scope out for near-term implementation
Below are the items that the development team understands well enough to implement, and is currently working on a schedule for. Many of the following ideas were copied and adapted from w:Wikipedia:Pending changes/Closure:


 * Speed improvements on reviewing
 * Displaying old revisions on diff pages
 * Upon pressing "accept"
 * Fix easy/obvious usability warts
 * More common names for PC specialpages (e.g. change "OldReviewedPages")
 * Less confusion around accept/unaccept - Unaccept button should be hidden when inactive, not greyed out.
 * See w:Wikipedia:Pending changes/Feedback and w:Wikipedia:Pending changes/Feedback
 * Note: this is already in trunk. See the test wiki
 * Proper "reject" button - a clearly labeled "Reject" button tied to the rollback or undo action on the review form using the reason entered as the summary
 * See Pending changes/Feedback and the current specification
 * A "stop reviewing" button that marks the pending change as no longer "under review". Alternatively this button could be called "put back in queue" or "defer". The desired effect can currently be achieved by accepting and then unaccepting an edit, but that's a hard one to explain and a single button would be much better.
 * A shorter timeout on the "under review", and/or use of Javascript to determine automatically when the review is no longer actively examining the article
 * Display a clear draft warning notice
 * Merge protection log and pending changes log
 * Formal usability pass
 * This may result in rethinking many aspects of this feature

Sounds easy, but needs info
These are ideas that sound reasonably straightforward, and appear to be candidates to move to the previous section, but need more clarification before we can do that.


 * Better links to documentation on PC related specialpages
 * Incorporate the PC protection rationale (protection log message) into the review screen as instruction to the reviewer.
 * Add short reviewer instructions to the review page
 * Quick link to Pending Changes specialpages
 * Notification of PCs on your watchlist
 * This may already be implemented

Need more info
These might be easy, or might be hard. We just don't know without more info.


 * Different logo for PC/Reviewers
 * Make page protection log more visible (reviewing depends on protection reason, but it's hidden by default) Is this the same as "Incorporate the PC protection rationale (protection log message) into the review screen as instruction to the reviewer."?

Needs serious research
These are ideas that are uncertain because they appear daunting on the surface. These won't make the cut without a serious push.


 * Less history clutter (see Pending Changes enwiki trial/Reversion collapsing)
 * Easier access to preview/edit from the review page, for on-the-fly edits to pending changes
 * Ability to leave short notes/questions for other reviewers on the review page itself
 * Ability for reviewers to add a comment without making a review decision - this could allow concerns to be left for other reviewers.
 * Ability to request expert advice on a review decision.(should add the page to a report)
 * If another user preempts a page under review, make notification to the reviewer more obvious
 * Chat window if multiple reviewers are reviewing the same revision. This would be really cool, but not an easy feature.
 * An assisted tool for handling large pending changes queues (something along the lines of Huggle or Igloo)—before we have a large pending changes queue—to prevent a self-defeating backlog
 * If we end up with a lot more pages under pending changes protection, Special:OldReviewedPages should allow some kind of filtering or ranking so that reviewers can focus their effort. e.g.
 * Separate out those pages that are on a lot of watchlists. It may be better for reviewers to concentrate on pages that they know about and pages on few watchlists.
 * Rank pages for each reviewer according to considerations such as direct association (whether it is on that users watchlist, how many edits the user has made to the page) and direct association with pages that have links in and out of the page under consideration. By default, a vreviewers Special:OldReviewedPages could order the pages according to the rank for that reviewer relative to the average rank for all users
 * Ability to supply a missing edit summary, or annotate an unclear/misleading one. (potentially this needs to apply to all articles, but PC would be a good start)

Depends on policy
These aren't necessarily difficult to implement, but have policy implications
 * Don't make reviewers who try to directly edit an article they're reviewing have to accept their own edits
 * The current behavior was the result of a lot of back-and-forth during the trial. This would need strong consensus before changing again.
 * An "accept" button/link on the watchlist or page history without loading the full diffs - using popups for example

Not planning to revisit
These are issues that the dev team isn't inclined to reopen without a lot more convincing:
 * Changes of terminology could make this feature much more understandable and usable.
 * See w:Wikipedia:Pending changes/Feedback and w:Wikipedia:Pending changes/Feedback point 7 and w:Wikipedia talk:Pending changes/Closure
 * "Review" sends the message to vandals (and other editors) that "accepted" means wikipedia has allowed invalid changes. Suggested "Review for obvious vandalism" (or whatever policy is agreed upon) to specify the precise depth and limitations of this type of review. Suggested term "Visible" rather than "Accepted"
 * Dev team response: this unfortunately is a conversational rathole that actually slowed down the launch of this feature in the first place. There would have to be exceptionally strong community-led consensus to change this or need to be the result of formal usability work; even leading a conversation about this is time consuming.  See w:Wikipedia:Pending changes/Terminology for the existing style guide which was arrived at after a fair amount of wrangling.