Misplaced Pages

:Pending changes: Difference between revisions - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 16:23, 4 February 2009 view sourceMion (talk | contribs)Extended confirmed users18,091 edits Scope: only the 3000← Previous edit Revision as of 05:22, 5 February 2009 view source Aaron Schulz (talk | contribs)Extended confirmed users26,051 edits Proposed configuration: remove untenable settingNext edit →
Line 91: Line 91:
); );
# Group permissions for autoconfirmed # Group permissions for autoconfirmed
$wgGroupPermissions = true;
$wgGroupPermissions = true; $wgGroupPermissions = true;
$wgGroupPermissions = true; $wgGroupPermissions = true;

Revision as of 05:22, 5 February 2009

The following is a feature request for Misplaced Pages, the details of which may still be in development or under discussion. As a whole, this request should be discussed with the developers, who will decide whether or not to act on it.
The following is a proposed Misplaced Pages policy, guideline, or process. The proposal may still be in development, under discussion, or in the process of gathering consensus for adoption.
This page in a nutshell: Flagged Revisions could be placed on an individual article in the same manner that protection currently is
Shortcuts

Flagged protection is a proposed implementation of flagged revisions which would provide an alternative to the current semi-protection feature to allow anonymous editors and new users to edit protected articles in a limited fashion. This proposal is meant to give administrators another option besides the present full protection and semiprotection. (It is possible that, some time in the future, this might displace the present semiprotection altogether, however, this proposal does not yet suggest that the traditional system of page protection should be replaced altogether, merely suggesting flagged protection can be used as an alternative to the current system of page protection for now. Although if there is a consensus, flagged protection may become more favorable as time progresses.)

Problem Statement

One of the problems that this proposal is trying to solve is that there are many articles that are semi-protected. While 3,000 might not sound like a huge number of semi-protected articles, in reality, only articles that receive a good amount of traffic are semi-protected. Since these are high-traffic articles, there will naturally be many people who want to legitimately contribute to the article. Though it makes us somewhat safer from vandalism, semi-protection locks out people who want to legitimately contribute to an article. Although anonymous and new users can use the {{editsemiprotected}} template to suggest changes to the page, it is very tedious and daunting to use, especially if one has never edited Misplaced Pages before. Therefore, this system is designed to replace the need for {{editsemiprotected}}, and to allow users to directly make changes to the article without knowing how to use the template.

Scope

Like the name of this proposal, only the 3000 articles that would otherwise be semi-protected should be considered for flagged revisions under this proposal. The condition for flagged revisions should be the same or similar as to what 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 either. As noted above, this proposal does not suggest that the current page protection system should be removed, or even fully replaced. Due to the lack of experimental data on flagged protection and solid consensus, it is proposed that as of now the choice of using the traditional page protection or flagged protection is up to administrator's discretion provided that there is a need for page protection on WP:RFPP. Usage policy for flagged protection should be updated as consensus develops if flagged protection is adopted. This implementation is intended to reduce the need for semi-protection on articles.

Experience

Protection type Anonymous / non-autoconfirmed Autoconfirmed Administrator / Bureaucrat
Semi-protected pages Current experience Cannot edit Can edit; edits are immediately visible
Semi Flagged protection Proposed experience Can edit; edits are visible to registered users, but are not visible to readers until reviewed by 'autoconfirmed' Can edit; edits are visible immediately if there are no unflagged edits by anonymous users; otherwise not visible to readers until reviewed by other 'autoconfirmed' 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'
Fully-protected pages Current experience Cannot edit Can edit; edits are visible immediately
Full Flagged Protection 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

How it works

All accounts with autoconfirmed rights gets reviewer rights and will have the ability to review any revision made by new accounts and anons, or simply put, if you can edit semi-protected articles, then you have the ability to sight revisions made by anons and new accounts. Administrators will have surveyor rights.

The process will work like this:

  1. Article receives heavy vandalism from anons or users that have yet to be autoconfirmed
  2. Someone requests flagged protection on WP:RFPP
  3. Administrator activates flagged revisions on the article
  4. Anon makes a legitimate edit to the article
  5. An autoconfirmed user can decide to sight or revert the revision made by the anon

The basic workings of flagged revision can be previewed here, except in this implementation, there is no need to set user rights to sight revisions.

Tools

Procedure on dealing with vandalism

When reviewing a valid edit, simply sight the edit and move on. If the edit is vandalism, revert it. Reverting vandalism on an article with flagged protection is essentially the same as it is without it, the only difference being that the vandalised version of the article will not appear to the public. However, if an editor attempts to edit the latest version of the article, regardless if the latest version is visible to the public or not, it is very important that the vandalised revision be reverted, since these edits could end up in the next revision without the editor knowing about the edit. The role of RC-patrolling will be vital on articles with flagged protection on.

Note for editors

When you edit the article, by default, you are editing the latest version. A diff will be shown above the edit page if there are any changes since the last sighted version. When you edit, you may be editing the draft that contains vandalism because the previous anon editor has vandalised the article even though the vandalism is not visible to the public. If you do find any vandalism that has not been reverted yet, you must revert the edit in order to ensure the vandalism does not make it into the next revision, even if you do not plan to edit that article.

Full Flagged Protection

Full flagged protection is similar to flagged protection as described above, but with the reviewer rights limited to the group administrators like the full protection counterpart. This could be used as an alternative to full protection during disputes or for articles under heavy vandalism attacks from sock-puppet accounts. Administrators can elevate an article to full flagged protection, in accordance to the current page protection policy with regards to full protection. Full flagged protection can also be used alongside the traditional semi-protection to allow only autoconfirmed accounts to make even draft edits to the article, to be sighted by administrators later on, although this should be used with very great caution and double protect like this should be kept as brief as possible. The rights to flag a full flagged protected page may be extended to a new user group, 'moderators', if the admin group is too small.

Proposed configuration

The following is the tentative proposed configuration for this setup:

# 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 (full=2/semi=1/none=0)
$wgFlaggedRevValues = 2;
# Restrict autoconfirmed to flagging semi-protected
$wgFlagRestrictions = array(
    'protection' => array( 'review' => 1 ),
);
# Group permissions for autoconfirmed
$wgGroupPermissions = true;
$wgGroupPermissions = true;
$wgGroupPermissions = true;
# Group permissions for admins
$wgGroupPermissions = true;
$wgGroupPermissions = true;
# We're using autoconfirmed, so we don't need this
$wgFlaggedRevsAutopromote = false;
# Can users make comments that will show up below flagged revisions?
$wgFlaggedRevsComments = true;

The default values for these variables and other unchanged variables can be seen on SVN.

Categories: