- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The scheduled two-month trial has ended. The community should now decide if the implementation is to be continued, and it should discuss possible adaptations, in terms of policy. Developers have indicated it would be too complex to turn off the feature, then turn it back on in case the decision is in favor of continuing the implementation, so they will wait for the community decision — unless it takes more than a month, in which case they will turn off the feature. In the meantime, it is possible to ask administrators to stop adding new pages under pending changes.
Working Summary (unofficial)
This section should briefly list issues. Transfer ideas to this informal summary. Neutral phrasing appreciated. May get edited for clarity. Please keep discussion in other sections. It is not necessary for everyone to agree that every point is valid, just to get a consensus on which issues have been identified.
Pros (what worked)
- - Allowed IPs (anonymous users) to continue to edit
- - Allowed systematic page monitoring
- - Kept most vandalism from appearing
- - Pending Changes queue cleared quickly
- - Adds another option between 'open' and indefinite semi-protection
- - Some reviewers enjoyed looking at pages that they might otherwise have had no reason to look at.
Cons (what didn't work)
User interface / Usability
- - Speed issues with loading diffs
- - Confusing accept/unaccept scheme
- - Complicated to review multiple edits. Some good intermediate edits could be missed if followed by vandalism.
- - Causes "review conflict"
- - Review summary not visible in edit history; you have to cross-ref the edit history and the review log to get the full picture
- - Some people are unhappy about the way pending changes are highlighted on the watch list
- - Complicates editors' seeing and correcting errors they made if the errors were not caught during preview
- - Relative to semi-protection, "clutters" edit history with vandalism/reverted edits
Vandalism / Workload
- - Some users accepted false additions that would have been obvious to someone familiar with the article or who looked at it
- - Some pages continue to suffer large amounts of IP/unconfirmed-user vandalism and so might be better to have semi-protection
- - Pages with a high frequency of edits have multiple problems
- - Creates a high workload for reviewers. Some reviewers may be put off by seeing the same page appearing repeatedly at Special:OldReviewedPages.
- - These pages often accumulate pending changes from multiple users, which leads to further problems
- - More complex for reviewers to review
- - Helpful, auto-confirmed (non-reviewer) editors are being denied instant gratification and possibly being confused, which would not be the case with semi protection.
- - IP editors will be editing a version of the page that they may not have seen.
- - It can appear that the reviewer is taking sides in an edit war. Even if the reviewer accepts multiple versions, only the last accepted version will get its time being visible to non-logged-in users.
- - Sometimes these pages attract multiple different vandals and hence putting off one vandal, by denying instant gratification, may be less successful than on low-edit-frequency pages.
- - Failed to achieve a desirable effect in at least one instance
- - Counterproductive on pages protected due to sockpuppetry
- - Can be exploited as a sophisticated form of vandalism; potentially creates an extra incentive for subtle vandalism, i.e. Vandals may feel a sense of achievement if they get their vandalism accepted. Provides an extra system for disruptive people to game
- - The ratio of manpower : effect is inefficient when compared to semi-protection; in some cases, the amount of time necessary to manage vandalism increased rather than decreased
- - Vandalism removed by IPs will still be visible until someone accepts the change
- - Increases chances that subtle vandalism won't be detected if people see the "accepted" status as a sign that things are OK
- - Because PC stops IPs from seeing vandalism, they won't be helping out with reverting or fixing that vandalism; relegates vandalism fixing tasks and patrolling in PC articles to autoconfirmed users only, increasing their workload and preventing others' ability to assist
- - May be perceived as a burdensome and bureaucratic process in general
- - May increase the perception of a hierarchy amongst PhysicsWikins
- - May inadvertently result in article ownership and/or soft-censorship of conflicting POVs
- - Can put off new users in a way that neither "no protection" nor "semi protection" can. i.e. IP goes to an article and makes a constructive change, clicks save, but doesn't see his or her edit in the article. Figures, "doesn't work", or "too complicated to figure out", and never edits again
- - Disrupts the Bold-Revert-Discuss cycle
- - Some editors inadvertently unaccepted good edits on subjects with which they were not familiar, causing battles
- - Unclear or controversial guidelines for reviewers led to conflicts
- - Fewer users see a change in an article before it is reverted. Some users who would have seen a good change, and questioned its removal, won't even know about it to go to bat for keeping it in.
- - An IP may want to edit constructively, but is addicted to instant gratification, so doesn't bother editing at all.
- - Inconvenient for users to check each others reviewing behaviour (Most users are unaware of Special:AdvancedReviewLog or that it can be filtered by user; even if you know this, it is several clicks away)
- - May conflict with one or more of PhysicsWiki's founding principles
- - Proposed policy level implantation does not offer Wikiprojects, working groups, or other editor-based article improvement units the option of interpreting and applying such protection for their articles if they so wish.
Feature Requests (what might make it better)
User interface / Usability
- - 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.
- - Different logo for PC/Reviewers
- - Unapprove button should be hidden when inactive, not greyed out.
- - Clearly labeled "Reject" button tied to the rollback or undo action on the review form using the reason entered as the summary
- - More common names for PC specialpages, and a quick link to PC specialpages, in addition to notification of PCs on your watchlist
- - 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.
- - Make it faster
- - An "accept" button/link on the watchlist or page history without loading the full diffs - using popups for example
- - 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."?
- - Add short reviewer instructions to the review page
- - Easier access to preview/edit from the review page, for on-the-fly edits to pending changes
- - Don't make reviewers who try to directly edit an article they're reviewing have to accept their own edits
- - 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
- - 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 reviewers Special:OldReviewedPages could order the pages according to the rank for that reviewer relative to the average rank for all users
- - Changes of terminology could make this feature much more understandable and usable.
- "Review" sends the message to vandals (and other editors) that "accepted" means PhysicsWiki 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"
- 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)
- - Need to better define when to use semi-protection instead of pending changes (leading to changes to PhysicsWiki:Protection policy)
- - Further work to establish consensus on what reviewing means. Ideas for changing PhysicsWiki:Reviewing include:
- - Encourage people to stop reviewing if they are unsure.
- - A more clearly defined process for handling edits that are clearly nonconstructive, but may not fall squarely into one of the nonacceptance criteria.
- - Need to respond swiftly to reviewers who use PC to censor views they disagree with.
- - More prominent description of how to review other reviewers
- - PC protection should be used mainly/exclusively on pages with a low frequency of edits 
- - Works best on certain types of article. e.g. For articles in Category:Surnames and Category:Given names, a lot of the IP edits are vandalism but some are not and so the pages gain information that they would not with semi protection.
Expansion or contraction (beyond policy and pure numbers of articles)
- - A possible "PC3", with which all edits must be reviewed by an administrator prior to appearing in the "stable version" for possible trial as an alternative to full protection
- - Possibly remove the option of PC2. It increases the power of reviewers to censor other PhysicsWikins.
- - Ability to "defer" edit(s) on an article that is not under Pending Changes protection
- - Most likely using a modified PhysicsWiki:Edit filter
- - Possibly tie in with RC patrol, particularly when assisted with RC patrol tools such as Twinkle, Igloo, and Huggle - allowing for implementation of a "2nd opinion" feature completely within Mediwiki
- - However it is done, indicate why the change is flagged for review on the review screen
Open questions (what was unclear)
- - Did vandalism attempts go down on PC pages?
- - Did the timing of the trial--during the June to August period when there is a drop in vandalism levels--skew results?
- - What percentage of IP/unconfirmed edits were "good edits"?
- - Is PC better for high or low traffic pages?
- - Are reviewers checking "good edits" or just preventing "vandalism"?
- Check for obvious deficiencies?
- Check for vandalism only?
- Enforce reliable sources?
- All of the time?
- When a change looks questionable?
- - Is PC for protection (use on problem pages only) or prophylaxis (use on many pages)?
- - Will reviewing rights be taken away as sanction for bad behavior?
- - On what grounds should an editor be denied "reviewer" status?
- Disregard for reviewer guidelines?
- Disregard for PW:COI
- Editors with a recent history of vandalism, blocks, or other sanctions that would indicate poor judgment?
- Editors who have previously (recently?) had reviewer status taken away for poor judgment?
- - Should "reviewer" status be auto-confirmed, e.g. based on X number of edits or X amount of time?
- Should be relatively easy to get, but not auto-confirmed - a defense against "sleeper" accounts is required to prevent vandals from getting the reviewer permission, especially if we let up on RC patrol on "reviewed" articles.
- - Would the pending changes queue have a backlog if PC was expanded to many more pages?
- - Should PC be expanded to BLPs, low-traffic pages, or other articles?
- - Does the similarity of PC to Citizendium's approved content model indicate similar intentions or consequences?
- - What would the 5,000 or so reviewers be doing otherwise, if they weren't reviewing articles?
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.