Pending Changes enwiki trial/Feature ideas

Features considered during creation of Pending Changes enwiki trial/v2 Features

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.