Wikipedia:Flagged protection and BLPs

For the latest developments on similar features, please see Wikipedia:Flagged protection and patrolled revisions.

Rationale

Background

Semi-protection and full-protection are a technical means to prevent an article being edited by anonymous and non-autoconfirmed users in the case of semi-protection, and all users except administrators in the case of full-protection. The semi-protection policy indicates that this should be used in cases of persistent vandalism or of content violations, giving the example of violating the policy on the biographies of living persons. Protection in both forms does, however, bring the disbenefit of preventing contributions from good-faith editors as a result of persistent bad-faith contributions from a minority.

Wikipedia has policies relating to the biographies of living persons (BLPs), with the specific intent of strictly enforcing our content policies of verifiability, neutral point of view, and assorted others with the rationale:

Wikipedia is a high-profile, widely-viewed website with an international scope, which means that material we publish about living people can affect their lives and the lives of their families, colleagues, and friends. Biographical material must therefore be written with strict adherence to our content policies.

This has formed the basis of multiple discussions on how to prevent harm to living subjects, particularly those who are not sufficiently prominent to be widely watchlisted meaning that vandalism goes unnoticed for longer, allowing more readers to view the article and potentially damage the person being discussed. One such proposal has been to permanently semi-protect all BLPs, but the counter-arguments to this are that new or anonymous editors also make positive contributions and that autoconfirmation is not a useful threshold to avoid editing by determined vandals.

Protection as it stands can therefore be seen as a blunt instrument against content violations, which has been necessary because there were no technical alternatives available.

Summary of proposal

This proposal seeks to do two things:

• Adopt a compromise between "anyone can edit" and "only a select group can edit" on protected articles, by adopting a principle of "anyone can contribute" using the software capabilities of the Flagged Revisions extension. This is increasing participation.
• Adopt the same principle of "anyone can contribute" on BLPs, whilst not letting those edits show up in the default version of the page so that living people are protected.

Normally, a user part of a usergroup able to flag pages will automatically flag a page as visible to all readers when they edit the page - there will be an additional step if they are editing the draft of an unflagged version, which will require a manual check of the diff and a manual approval for it to become visible. This additional step requires a negligible amount of time for semi-protection replaced by flagged protection.

If adopted, this proposal would affect the following categories of editor in the following ways

Protection type		Anonymous / non-autoconfirmed	Autoconfirmed	Reviewer	Administrator / Bureaucrat
Unprotected pages	Current experience	Can edit; edits are immediately visible
	Proposed experience	Can edit; edits are immediately visible
Semi-protected pages	Current experience	Cannot edit	Can edit; edits are immediately visible
	Proposed experience	Can edit; edits are visible to registered users, but are not visible to readers until reviewed by 'autoconfirmed' or 'reviewer's	Can edit; edits are visible immediately if there are no unflagged edits by anonymous users; otherwise not visible to readers until reviewed by 'autoconfirmed' or 'reviewer's	Can edit; edits are visible immediately if there are no unflagged edits by anonymous users; otherwise not visible to readers unless the reviewer or other 'autoconfirmed' or 'reviewer's flag them.	Can edit; edits are visible immediately if there are no unflagged edits by anonymous users; otherwise not visible to readers unless the administrator flags them, or flagged by 'autoconfirmed' or 'reviewer'
Biographies of Living People	Current experience	Can edit; edits are immediately visible
	Proposed experience	Can edit; edits are visible to registered users, but are not visible to readers until reviewed by 'reviewer's		Can edit; edits are visible immediately if there are no unflagged edits by anonymous users; otherwise not visible to readers unless a 'reviewer' flags them	Can edit; edits are visible immediately if there are no unflagged edits by anonymous users; otherwise not visible to readers unless the administrator flags them
Fully-protected pages	Current experience	Cannot edit			Can edit; edits are visible immediately
	Proposed experience	Can edit; edits are visible to registered users, but are not visible to readers until reviewed by administrators			Can edit; edits are visible to registered users, but other intervening edits are not visible to readers unless an administrator flags them

In a previous discussion about flagged protection, which encapsulates the protected page portion of this proposal, autoconfirmed was deemed the appropriate level since it opens the protected portions of the project to everyone without imposing greater restrictions. The role of the Reviewer permission is required in some form since the Autoconfirmed threshold is considered by many to be too low to prevent damaging material being added by determined vandals/libellers. Rather than create a new usergroup for reviewers of all flagged articles, it will be less bureaucratic to simply spin out a usergroup that can review the edits to BLPs. Since BLP checking requires a different set of checks to standard reviewing, it is also worthwhile separating. See also #Userrights.

Proposed usage

Protected, non-BLP pages

See also: Wikipedia:Flagged protection

For the protected, non-BLP pages, this proposal broadly enacts the same principles and policies required by WP:Flagged Protection, except that it is explicitly subject to the protection policy in its application. The conditions are summarised in this section for convenience

The condition for normal flagged protection should be the same as the current semi-protection policy allows. If the article does not meet the requirements for semi-protection under the current semi-protection policy, then it should not be protected with flagged revisions. This proposal seeks to ultimately eliminate the need to use traditional page protection methods in favour of flagged protection, but for now, this choice remains at the discretion of the protecting administrator.

Full flagged protection is similar to the protection described above, but with the reviewer rights limited to the group administrators like its full protection counterpart. This can be used as an alternative to full protection during disputes or for articles under heavy vandalism attacks from sock-puppet accounts, subject to the same requirements . Administrators can elevate an article to full flagged protection, in accordance to the current protection policy.

Autoconfirmed and other editors reviewing edits to these articles should simply check if the edit adds obvious vandalism, as RC patrollers do at present. If not, the edits must be approved for display, otherwise the edit to the draft should be reverted. Autoconfirmed users editing a previously approved draft will have their edits automatically reviewed. If the draft they are editing is unapproved, manual review and approval will be required before the draft is displayed as the default.

Protection for BLP pages

The restrictions of the protection policy will not apply in the application of flagged revisions to BLPs, and all would be flagged if this proposal were implemented fully (beyond a trial phase).

The members of the Reviewer group will be required to review edits to BLPs to check, in addition to the requirements for flagging normally protected articles, whether the edit is compatible with the explicit requirements of the BLP policy with relation to the sourcing of contentious statements.

Trial conditions

Before any full implementation, a trial must take place. This section outlines the scope of a trial and the means of determining its success.

1. Pre-trial

Once a trial is approved, there will be a delay until the following is complete:

• A site-notice will be placed for one week informing all users, anonymous and registered, of the trial changes by a link to an appropriate page.
• The software configuration will be activated, but no pages will be flagged
• Volunteers for the Reviewer group shall be sought and an appropriate number shall be granted the necessary rights. The number to be granted needs to be considered as relative to the number of articles being flagged, otherwise an incomplete picture of the backlogs will be obtained.
• 2000 articles from Category:Living people will be selected at random, and checked to ensure they are in a flaggable state prior to implementation of the trial.
• 1000 of the articles will then be chosen at random and subjected to Flagged Revisions; the other 1000 will be a control group.

2. Trial

• The trial shall continue for no longer than three months, and commences as soon as all articles are flagged
• During this time, the chosen BLPs will be flagged. All protected articles will have the existing protection lifted and flagged revisions applied. These tasks may be performed by a bot.
• After two months, there should be sufficient data for an analysis by all sides. The discussions should consider the two elements of this proposal as distinct - it is possible to have one without the other.
• The subsequent community discussion should again be advertised on a sitenotice
• As the trial comes to an end, a bureaucrat should close the discussion, allowing the possibility of a consensus that the flagged protection or BLP elements of the trial may be retained without there being a consensus to retain both. The status quo in the event of no consensus either way should be Wikipedia without flagged revisions

3. Post-trial

• If consensus to retain either portion of the configuration does not exist, then all articles shall return to their previous state of protection or otherwise, and all additional userrights and page flagging will be revoked.
• If consensus for retaining flagged protection exists, then the trial can end and continue as a full implementation.
• If a consensus for retaining BLPs exists, it may be worth considering simply extending the trial by a particular period of time, and additionally increasing the number of flagged BLPs. Membership of the Reviewer group would become unrestricted, and a further analysis would be performed after a further period of time to review whether the flagging principle is sustainable at increasing sample sizes. If it becomes unsustainable after a certain point, a further discussion would have to take place to decide how to handle BLPs in this context.

Proposed configuration

Userrights

• Autoconfirmed users receive the ability to review protected pages when they become members of that usergroup
• Reviewer group membership should be granted by request in the first instance in a similar fashion to Rollback - a user in good standing should be able to acquire it with ease, and have it removed for abuse, with dispute resolution through the usual channels. The reason to keep two separate groups is that Rollback has a very specific purpose, and this scope should not be needlessly extended. There is an option to auto-promote to this group if the community deem it necessary
• Administrators, and therefore all higher usergroups, will have the ability to grant and revoke Reviewer group membership. As such, it is logical that they are members of this usergroup.
• Bots will be granted auto-review rights, but may not review edits. Automated flagging of edits is counter-productive, and must not occur.

Technical configuration

This is a tentative configuration which may require altering - based on User:Mr.Z-man/yet_another_FlaggedRevs_proposal.

# Limit it to mainspace only
$wgFlaggedRevsNamespaces = array( NS_MAIN );
# Don't set any FlaggedRevs level for new pages
$wgFlaggedRevsAutoReviewNew = false;
# Pages display the current version by default - i.e. unprotected
$wgFlaggedRevsOverride = false;
# This requires it to be turned on by an admin for each page
$wgFlaggedRevsReviewForDefault = true;
# Flagging types
$wgFlaggedRevTags = array( 'protection' => 2 );
# Number of levels (BLP/full/semi/none)
$wgFlaggedRevValues = 3;
$wgFlaggedRevPristine = 3;
# Lets "pristine" (BLP) revs override
$wgFlaggedRevsPrecedence = 2;
# Restrict reviewers to flagging semi-protected
$wgFlagRestrictions = array(
    'protection' => array( 'review' => 1, # editors
		'blp-review' => 3, # BLP reviewers
		'protect' => 2 # admins
));
# Group permissions for editors
$wgGroupPermissions['editor']['review'] = true;
$wgGroupPermissions['editor']['autoreview'] = true;
$wgGroupPermissions['editor']['unreviewedpages'] = true;
# Define the extra right for BLP reviewers
$wgAvailableRights[] = 'blp-review';
# Rights for BLP Reviewers,
$wgGroupPermissions['reviewer']['blp-review'] = true;
$wgGroupPermissions['reviewer']['stablesettings'] = true;
$wgGroupPermissions['reviewer']['review'] = true;
$wgGroupPermissions['reviewer']['autoreview'] = true;
$wgGroupPermissions['reviewer']['unreviewedpages'] = true;
$wgGroupPermissions['reviewer']['movestable'] = true;
# Group permissions for admins
$wgGroupPermissions['sysop']['stablesettings'] = true;
$wgGroupPermissions['sysop']['review'] = true;
$wgGroupPermissions['sysop']['autoreview'] = true;
$wgGroupPermissions['sysop']['unreviewedpages'] = true;
$wgGroupPermissions['sysop']['movestable'] = true;
# Give bots autoreview
$wgGroupPermissions['bot']['autoreview'] = true;

# Give admins the ability to add/remove reviewer
$wgAddGroups['sysop'][] = 'reviewer';
$wgRemoveGroups['sysop'][] = 'reviewer';

# How many pages count as a backlog?
$wgFlaggedRevsBacklog = 500;
# Remove unused  groups
unset($wgGroupPermissions['autoreview']);