Misplaced Pages

This is an old revision of this page, as edited by AndrewRT (talk | contribs) at 01:21, 29 August 2009 (Quick-adding category Misplaced Pages flagged revisions (using HotCat)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

The aim of this page is to find an implementation of the extension FlaggedRevs that can match the proposed trial implementation, agree on the details, and fix the wording of system messages. A bug for a test implementation has been opened: Template:Bug.

Configuration details and requests

Below are configuration details and requests specific to the implementation. They should be completed and modified based on discussions.

Implemented in configuration

•  Done. A revision can be confirmed/semi-reviewed by a reviewer only when the page is semi-flagged protected (and not when fully flagged protected).

•  Done. A revision can be validated/fully-reviewed by an administrator only when the page is fully flagged protected.

•  Done. Reviewers are autopatrolled.

•  Done. Autoconfirmed users are auto-semi-reviewed / autoconfirmed (!), unless it is specifically disabled on the page.

•  Done. A page is semi flag protected when the latest semi-reviewed revision is set as stable.

•  Done. A page is intermediary (between semi and full) flag protected when the latest semi-reviewed revision is set as stable and non-reviewer (auto)review is deactivated.

•  Done. A page is fully flag protected when the latest fully-reviewed revision is set as stable.

•  Done. Patrolled implies confirmed/semi-reviewed (for semi flag protected pages)

•  Done. Validated/fully-reviewed implies patrolled (for fully flag protected pages)

•  Done. Patrolling a new page should automatically mark the revision patrolled in the Special:NewPages sense (not reciprocal).

•  Done. All articles can be patrolled (including flagged protected ones).

•  Done. "Stabilize" tab for admins to access Special:Stabilization from articles, right of protect? Currently linked from protection page.

•  Done. Patrolled revisions are invisible for reviewers when editing:

1. The diff to the latest patrolled is not shown to reviewers when editing
2. There is no patrolling box at the bottom of pages and revisions

•  Done. Patrolled revisions are invisible to readers (no icon, no draft page, no 'unflagged' banner).

•  Done. When editing, like for protection, the latest entry of the stabilization log should appear.

•  Done. If active, the latest entry of the stabilization log appears below the reviewing/patrolling box.
  • Is this necessary? Aaron Schulz 00:58, 31 March 2009 (UTC)
    • On a flag protected page, users should give special consideration to the reason for protection when reviewing, as reviewing is meant to uphold the protection, it may be very specific to the article and circumstances e.g. sockpuppets, POV-pushing, etc. So it would be appreciable to have the reason visible directly, and not have to check the log. As for patrolling, it would depend if patrolling implies reviewing, I'm still unsure about that. Cenarium (talk) 17:51, 1 April 2009 (UTC)

•  Done. A page listing pages by flag protection status, similarly to Special:ProtectedPages.
•  Done. Edits in recent changes in main namespace lose '!' marks only when patrolled.
•  Done. When a page is semi flagged protected, the revision at the time of protection should be automatically reviewed, and when a page is fully flagged protected, the revision at the time of protection should be automatically validated. This is done to avoid that the stable version becomes an old version from previous protections. Thus, there is no need for Special:UnreviewedPages and Special:UnvalidatedPages.
  • Is this necessary? Currently users are notified if it is out of date, and given a diff. This makes sure they actually know what is being reviewed. Aaron Schulz
    • As an article cannot be reviewed when it's not already flag protected, in most cases, there wouldn't be any reviewed version or they would be old. If we don't do it automatically, we'll probably have flag protected pages with no reviewed revision, so it won't have any effect, or with an old revision as stable, which would be even worse. In cases of dispute, the revision should also be 'locked' at the time of protection for neutrality. I'm sure admins wouldn't pay attention to actually reviewing the whole article when (flag) protecting (review is a bit misleading in this regard, maybe 'confirm' would be a better name), but it won't mark the revision patrolled as there are no precedence. Cenarium (talk) 17:51, 1 April 2009 (UTC)

Not yet implemented

• There are (patrol) links in recentchanges and watchlists for reviewers. Thus flagged protected pages would have both (review) and (patrol) links.
  • Seems a tad cluttered. Aaron Schulz 00:01, 4 April 2009 (UTC)
    • Then, since patrol implies semi-review, it should be enough to only show (patrol) links and have a distinctive mark for flag protected pages (those should be highlighted as they are more urgent to review). If there are no patrolled revisions, it should just show the page with the 'unpatrolled' banner. Cenarium (talk) 00:42, 11 April 2009 (UTC)
• To distinguish between unpatrolled edits and unconfirmed edits (on semi flag protected pages), maybe we could use two colors for ! marks: red for unconfirmed edits, and orange for unpatrolled edits. Cenarium (talk) 20:36, 24 April 2009 (UTC)
• Since patrolled implies semi-reviewed/confirmed, we won't have revisions with both (patrolled) and (confirmed), so it should be okay to show all notes. To avoid having a revision noted as both patrolled and validated, we could also make that validate implies patrol, it should be safe as fully flag protected pages should have enough scrutiny. In the end, we would have those cases only:

  Cenarium (talk) 00:42, 11 April 2009 (UTC)

• API support.
  I'm not yet quite sure what information and functionality should be exposed through the API, but at the very least it should be possible to get the type of flagged protection, get the last patrolled/reviewed/validated revision id, possibly get the number of revisions since then, set a revision as patrolled/reviewed/validated, and possibly set the type of flagged protection. It might be useful to get the full spread of patrol/review/validation information, i.e. get revisions with which editor patrolled/reviewed/validated it, and when. From how I read mw:API:Calling internally it's not possible to simply extend action=query&prop=revisions, but that would of course be preferrable.
  I don't currently have reviewer rights on any Misplaced Pages (and test-wiki is currently down) so I have a hard time imagining what information will be useful. I'd think that we certainly want a NAVPOP link showing the diff between the latest flagged revision and the current revision, with simple means to flag the current revision, so that I can in simple cases do this from my watchlist without actually opening the page.
  Amalthea 12:48, 14 April 2009 (UTC)

  Template:Bug mentions API and flaggedrevs. Cenarium (talk) 22:32, 27 April 2009 (UTC)

• An exception to validated implies patrolled: fully flag protecting a page shouldn't automatically make the revision patrolled (even though it validates it). Cenarium (talk) 03:19, 4 May 2009 (UTC)
  • Why is this? And why not for semi too? 164.107.220.208 (talk) 02:15, 23 July 2009 (UTC)
    • Suppose there's an edit war going on on an article not recently patrolled, an admin comes along, check if there's indeed an edit war, protect the page and move on (this is how it happens in most cases). There's no guarantee the article will be checked, the edit-warring users would probably not be reviewers, etc. The article would be marked as validated to make work immediately the precedence of the version at the time of protection. But it shouldn't make the revision patrolled, because it's not sure the revision has been checked. Maybe the software shouldn't actually mark the revision as validated, but give precedence for the version protected at the time of edit until the protection expires or a more recent version is validated. For semi, making the protection makes the version confirmed, but it won't make it patrolled since confirmed doesn't imply patrolled, so the problem doesn't arise. Though maybe we could also not actually confirm the revision, but give it precedence until the protection expires or a more recent version is confirmed. Cenarium (talk) 13:27, 23 July 2009 (UTC)

Special pages

They are all filterable by category and reviewer-restricted.

•  Done. UnpatrolledPages – pages that have never been patrolled (regardless of the flagged protection status). This can be done by filtering Special:UnreviewedPages on 'patrol'.
•  Done. OldPatrolledPages – pages patrolled at least once with an unpatrolled latest revision (regardless of the flagged protection status, although being able to filter by status may be interesting). This can be done by filtering Special:OldReviewedPages on 'patrol'.
•  Done. OldReviewedPages – semi flagged protected pages (only) with an unreviewed latest revision. This can be done by filtering Special:OldReviewedPages on 'semi-review'.
•  Done. OldValidatedPages – fully flagged protected pages (only) with an unvalidated latest revision. This can be done by filtering Special:OldReviewedPages on 'full-review'.
•  Done. Special:PatrolledPages implemented. This can be done by filtering Special:ReviewedPages on 'patrol'.

PHP configuration

# Limit it to mainspace only
$wgFlaggedRevsNamespaces = array( NS_MAIN );
# Allow auto-patrolling
$wgFlaggedRevsAutoReview = 2;
# Don't set any FlaggedRevs level for new pages
$wgFlaggedRevsAutoReviewNew = false;
# Pages display the current version by default - i.e. unprotected
$wgFlaggedRevsOverride = false;
# Hide flaggedrevs UI unless the stable shows by default?
# Pages are still reviewable from diffs/special pages.
$wgFlaggedRevsUIForDefault = true;
# Do quality revisions show instead of sighted if present by default?
# Set to 2 to make "pristine" versions override quality revisions.
$wgFlaggedRevsPrecedence = 0;
# Flagging types (full=3/passive patrol=2/semi=1/none=0)
# The status of a revision can be one of the above three.
# The software also has three tiers of "credibility"/"validation"
# for revisions that are flagged: stable, quality, pristine.
# This makes a bit more sense when there are multiple tags. 
# "Semi" is on the first tier, "patrolled" on the second, while
# "full" is on the third.
$wgFlaggedRevTags = array(
    'status' => array( 'levels' => 3, 'quality' => 2, 'pristine' => 3 ),
);
# Restrict autoconfirmed to flagging semi-protected
$wgFlagRestrictions = array(
    'status' => array( 'review' => 2 ),
);
# Semi-review should only show for semi-flag protected pages.
# Full-review should only show for full-flag protected pages.
$wgFlagAvailability = array( 
    'status' => array( 1=>FLAGGED_VIS_LATEST, 3=>FLAGGED_VIS_PRISTINE ),
);
# Restriction levels for auto-review right at Stabilization page
$wgFlaggedRevsRestrictionLevels = array( '', 'editor', 'sysop' );
# Group permissions for autoconfirmed
$wgGroupPermissions = true;
$wgGroupPermissions = true;
# Reviewer group
$wgGroupPermissions = true;
$wgGroupPermissions = true;
# Group permissions for sysops
$wgGroupPermissions = true;
$wgGroupPermissions = true;
$wgGroupPermissions = true;

System messages

Fix a wording for most visible system messages.

• MediaWiki:revreview-edited
• MediaWiki:revreview-editnotice
• MediaWiki:review-logpagetext
• ...

• Misplaced Pages flagged revisions