This is a failed proposal. Consensus for its implementation was not established within a reasonable period of time. If you want to revive discussion, please use the talk page or initiate a thread at the village pump.

The purposes of checkpointing and grading are to:

• Select the best revision for inclusion in a static release (paper, CD, DVD, etc.)
• Prevent backsliding of article quality over time
• Select a vandalism-free revision for display to the general public

Static releases could be more easily produced because:

• "Checkpoint" releases would be available for most articles, which are guaranteed to be vandalism-free
• Article grades would be available so that low-quality articles could be excluded if desired
• Obvious problems would be identified by maintenance tags on the checkpoint revisions, so those articles could be excluded.

Preventing backsliding would be easier because editors would not need to review any edits before the last checkpoint (unless the editor who designated the last checkpoint did a bad job). Editors would be more likely to check that long-term forward progress is being made, since this would become an explicit expectation of the checkpointing process.

The general public would see:

• The current revision for most articles, even if a checkpointed version were available. This minimizes confusion over current vs. checkpointed versions, and provides positive motivation for anonymous editing.
• The latest checkpointed revision for articles subject to frequent vandalism. This provides an alternative to semi-protection.
• The latest checkpointed revision for featured articles. Non-checkpointed revisions are more likely to be of lower, not higher quality than the revision "blessed" by consensus.

Administrators would be able to change the "show current revision/show checkpointed revision" setting on a per-article basis.

Motivation for creating this proposal:

• The "sighted" and "quality" proposals don't fulfill all of the identified needs.
• Requiring consensus on Wikipedia:Featured Article Candidates consensus for every update to every featured article is not sustainable. A lower-overhead process is needed to verify that the FA criteria still apply to a later revision.
• The "reliable" synthesis asks reviewers too many questions, surveying on accuracy, depth, and readability, when established practice is to use a single "grade" but use optional "tags" and talk page comments to indicate what kind of work is needed. Asking too many questions or allowing two competing grading systems to co-exist will result in lower participation in the revision-marking mechanism.
• The "reliable revisions" synthesis is inflexible, in that it does not allow "patrollers" to lower a quality rating, even if the quality of the article has in fact declined.

Graders include almost all logged-in editors, but they must be "autoconfirmed" (have an account a few days old).

Graders can assign any revision any grade on the Wikipedia:Version 1.0 Editorial Team/Assessment scale (FA/FL/A/GA/B/C/Start/Stub) according to the well-established criteria explained there.

Graders are expected to:

• Read the entire article
• Apply the grading criteria
• Add maintenance tags (cleanup, copyedit, citation needed, NPOV, etc.) if there are any obvious problems.
• Optionally add comments or todo items to the talk page.

Many articles are already tagged this way on their talk pages. Corresponding article revisions could be retroactively tagged, based on the timestamp of the existing assessment. Articles with stub tags could also have the latest revision retroactively graded "Stub" by a one-time transition sweep.

Perhaps eventually, revision grades would replace talk page grades, because it provides a specific revision for static releases (paper, CD, DVD, etc.) to pull. It wouldn't be feasible for the managers of a static release to pick a revision for 100,000 or a million articles, which they have to do if they are graded in a non-revision-specific manner. But the built-in and talk-page grading systems should be allowed to exist side by side for a while to see if the new system gains more traction, and what other modifications are necessary to provide the same functionality (such as producing lists of articles associated with a particular WikiProject that have a particular grade - currently handled within the category system).

Any editor can currently perform grading, so there is no reason to restrict access to this feature any tighter than the "autoconfirmed" group.

Checkpointers include almost all logged-in editors, but they must be "autoconfirmed" (have an account a few days old).

Checkpointers are expected to:

• Read the entire article if this is the first checkpoint, or examine the entire diff from the previous checkpoint.
• Ensure that the revision meets the Checkpoint Criteria:
  • There is no vandalism.
  • This revision is as good or better than the previous checkpoint, if any.
  • Any flaws in the existing material have maintenance tags (cleanup, NPOV, citation needed, etc.). (Incompleteness, unless it creates a POV or readability problem, need not be tagged, though it can optionally be mentioned on the talk page.)
  • There are no legal problems suspected - see Wikipedia:Biographies of living persons and Wikipedia:Copyright violations
• Optionally assign the article a grade. If no grade is assigned, the grade from the previous checkpoint will be inherited.
• Optionally add comments or todo items to the talk page.

If the current revision fails the Checkpoint Criteria, the checkpointer can either fix the article and declare the new revision to be a checkpoint, or decline to checkpoint the article.

Allowing a large number of editors to do checkpointing is critical to marking enough articles to do a large static release. It is also critical to keeping articles reasonably current for the general public when they are put on "display checkpointed revision" status.

Wikipedia:Flagged_revisions/Sighted_versions#Surveyor_rights lists slightly more stringent criteria which could be used if the checkpointing feature is abused by some "autoconfirmed" accounts.

Checkpointing featured articles

Checkpointing articles graded "Featured Article (FA)" or "Featured List (FL)" could (if necessary) be more difficult than checkpointing non-featured articles, since the newer revisions are more likely to be of lower quality than the revision "blessed" by the featured candidate consensus process. There are a few ways to do this:

• Don't do anything different on a technical level, but establish strong social norms and examine new checkpoints with a high level of social scrutiny.
• Require two "autoconfirmed" editors to checkpoint the same revision.
• Only allow these articles to be checkpointed by administrators, rollbackers, and editors meeting the criteria at Wikipedia:Flagged_revisions/Sighted_versions#Surveyor_rights
• Only allow these articles to be checkpointed by administrators and editors who have been manually granted the privilege by administrators.
• Only allow these articles to be checkpointed by administrators.

Restricting this ability beyond "autoconfirmed" editors makes the process less sustainable, and should only be done if the privilege is abused.

Graders, checkpointers, and readers in the general public are all encouraged to leave comments on talk pages, just as with current practice.

Wikipedia:Pushing to validation envisions three levels of validation:

1. A "stable" version free of vandalism
2. A "validated" version that has been fact-checked by Wikipedia editors
3. An "independently reviewed" version that has been fact-checked by an outside expert.

Checkpointed revisions do not provide any guarantee of accuracy, so they are the equivalent of the first ("stable") level. To accommodate levels 2 and 3, this scheme could be extended to allow revisions to be marked as a "validated checkpoint" or the grade "Validated FA/FL" to be assigned. These checkpoints, in addition to meeting the Checkpoint Criteria, would be required to be thoroughly referenced and fact-checked.