User:Cenarium/Proposal
 | The proposal is located at Wikipedia:Flag protection and patrolled revisions. |
The three propositions aim to improve our monitoring of vandalism, BLP violations, and other recurrent problems using systems inspired by flagged revisions, patrolled edits and the abuse filter, without affecting editability as is currently the case for page protection, or as it would be for large-scale implementations of strict flagged revisions. It relies on a 'reviewer' usergroup that can be granted automatically, and manually added or removed by administrators, able to flag or patrol articles.
Flag protection
[edit]For articles meeting the requirements for protection (defined by the protection policy)[1], flag protection may be used instead of regular protection, that is, instead of entirely preventing editing by unregistered or new users, we allow it, but non-autoconfirmed edits are delayed until reviewed by a reviewer.[2] Classic protection can still be used temporarily in cases of exceptionally high levels of vandalism or unstoppable edit wars. The proposed additional protection levels are:
- Semi flag protection: edits by non-autoconfirmed users are not shown by default to IPs until reviewed by a reviewer, edits by autoconfirmed users are automatically reviewed when the previous revision is already reviewed.
- Typical use: Excessive vandalism, repeated BLP violations, etc
- Full flag protection: a new revision is shown to IPs by default only when it is validated by an administrator (or possibly, users in a group moderator, if we don't have enough admins).
- Typical use: Disputes
- Option (disabled by default) to deactivate non-reviewer autoreview: only edits by reviewers are automatically reviewed when the previous version is already reviewed.
- Typical use: Pages targeted by persistent sockpuppeters [3]
- Option "Dispute": enabled by default, when editing, moderators are not proposed to validate their edits and there is no autovalidation. [4]
Summary tables:
| Currently available protection levels | Anonymous / Non-Autoconfirmed | Autoconfirmed | Reviewer | Administrator |
|---|---|---|---|---|
| Semi Protection | Cannot edit | Can edit; edits are immediately visible | ||
| Full Protection | Cannot edit | Can edit; edits are visible immediately | ||
| Proposed additional protection levels | Anonymous / Non-Autoconfirmed | Autoconfirmed | Reviewer | Moderator / Administrator |
|---|---|---|---|---|
| Semi Flag Protection a | Can edit; a new edit is visible to registered users, but not to readers by default until reviewed by a 'reviewer' | Can edit; a new edit is visible immediately if the previous version is already reviewed; otherwise[5]not visible to readers by default until reviewed by a 'reviewer' | Can edit; a new edit is visible immediately if the previous version is already reviewed or when the option "review this revision" is selected[6]; otherwise left unreviewed[7] | |
| Full Flag Protection b | Can edit; new edits are visible to registered users, but not to readers by default until validated by a 'moderator' [4] | |||
- ^a + option (enabled by default): Autoreview autoconfirmed users
- ^b + option (enabled by default): Dispute
- Advantages over the current system
- IPs and new users can edit semi flag protected pages, while they cannot edit semi-protected pages.
- When a page is fully protected, only admins can edit and the article development is made very difficult, especially for long-term protections, using intermediary or full flag protection in those cases would allow article development while keeping an independent validation of edits by reviewers or administrators/moderators.
- Semi-protection is insufficient in certain cases, especially for articles targeted by persistent vandals or sockpuppets, or subject to extreme BLP violations, they sometimes require full protection. An intermediary level between semi flag protection and full flag protection could handle those cases.
- Other
- Reviewers have access to Special:OldReviewedPages, listing all flag protected pages which a latest revision that is not reviewed.[8]
- When an autoconfirmed user edits a semi flag protected page, the new revision is automatically reviewed only when the previous one is reviewed (to avoid unnoticed vandalism insertions), which should be the case most of the time, as edits are continually flagged by reviewers.
Patrolled revisions
[edit]For all pages in mainspace, an enhanced system of patrolled revisions can be used. Reviewers can mark a revision patrolled, which has no effect but only to inform that this revision contains no vandalism and satisfy certain other requirements defined by a guideline.[9]
Reviewers have access to Special:UnPatrolledPages (pages that have never been patrolled) and Special:OldPatrolledPages (pages patrolled at least once with unpatrolled latest revision). Those special pages are filterable by category (especially interesting for Category:Living people). A new revision by a reviewer is automatically patrolled when the previous version is.
This system allows to improve the monitoring of pages for vandalism, blp violations, etc, by reducing the number of revisions to check and allow to compare the latest revisions with a previous 'good' version (acting like 'checkpoints').
This system would be entirely independent of flag protection, and would allow to double-check edits by autoconfirmed users to those pages.
Deferred revisions
[edit]For pages in mainspace, and possibly other namespaces such as Portal, Category, Template, Wikipedia, Help, File and User, we can use deferred revisions: edits that have been identified as suspect in some respect by an automated system (with customizable filters, like the abuse filter), are delayed until reviewed by a reviewer. Reviewers have access to Special:DeferredRevisions (listing all pages with a deferred revision that has not been canceled), and can cancel the deferral. Basic information on the filter triggered by the edit is given to the user whose edit has been deferred and to reviewers.
Edits are deferred when they match a certain filter, they can cover cases of obvious vandalism, spam, test edits and other potentially harmful edits. Each filter would require consensus to be turned on.
Technical aspect
[edit]For patrolled revisions and flag protection, the extension FlaggedRevs would be the core of the implementation, but certain modifications, such as adding new special pages and allow deactivation of non-reviewer autoreview are needed.
For deferred revisions, the abuse filter may be the automated system charged to identify and defer suspect edits, but substantial modifications are required to make the collaboration between the two extensions efficient.
Trial
[edit]This variant of flag protection has been proposed as a trial, see Trial 17.
Notes
[edit]- ^ Ultimately, policies for each protection types and options will have to be adopted.
- ^ A reviewer can review a revision only when the page is semi or fully flag protected, and a moderator can validate a revision only when the page is fully flag protected.
- ^ Such pages must sometimes be fully protected, examples: Bureaucracy, Witton Albion F.C..
- ^ a b This will allow to put all editors at the same place in cases of disputes, contrary to full protection which advantages admins. Although moderators can validate their own edits, this would be discouraged in cases of disputes.
- ^ This second case should happen much less frequently, as new revisions are continually flagged by reviewers.
- ^ When a reviewer edits a flag protected page with a latest revision unreviewed, the diff between the latest reviewed version and the latest revision is shown.
- ^ After editing a flag protected page with a latest revision unreviewed and when he option "review this revision" has not been selected, the diff between the latest reviewed version and the new revision is displayed, so the reviewer can choose to review or not at this occasion. If not, other reviewers can do this.
- ^ Special:ReviewedPages is available for all, and Special:UnreviewedPages should not be needed for this implementation.
- ^ This guideline should apply to all pages in mainspace (including redirects). For flag protected pages (which cannot be patrolled), the conditions to be reviewed should coincide or be stronger than for being patrolled (to assure compatibility and both form 'checkpoints').