Wikipedia:Flagged protection and BLPs
historical reference. . Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as the village pump |
- For the latest developments on similar features, please see Wikipedia:Flagged protection and patrolled revisions.
This page in a nutshell: biographies of living persons to uphold our own policies on the matter |
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
Wikipedia has policies relating to the biographies of living persons (BLPs), with the specific intent of strictly enforcing our content policies of
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
Proposed usage
Protected, non-BLP pages
For the protected, non-BLP pages, this proposal broadly enacts the same principles and policies required by
The condition for normal flagged protection should be the same as the current
Full flagged protection is similar to the protection described above, but with the reviewer rights limited to the group
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
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']);