Wikipedia:Deferred changes/Implementation

Editing of a page where a revision was recently actively deferred due to it being tagged as a redirect to a nonexistent page from mediawiki core.

The page details the proposed implementation of deferred changes.

Technical aspects

To defer an edit, flagged revisions is enabled on the page and the latest edit prior to the latest user is marked as reviewed. The page appears at Special:PendingChanges and the edits can be reviewed. If one of the tag is listed as needing 'active' deferral, then the stable version is displayed to readers by default.

A deferred page is recorded in the database with a "defer" level, and whenever an edit to a page with "defer" level is reviewed, the config is reset. So this implements the "defer until reviewed" concept. No change in the db schema is needed.

For AbuseFilter, two custom actions are added to defer passively or actively.

Bots can defer an edit with the API.

ORES may defer during its job, checking the damaging thresholds to apply for passive and active deferrals from MediaWiki pages on wiki. No commit exists for ORES yet.

FlaggedRevs can also check tags added in core or by extensions with the ChangeTagsUpdate hook. If any of the added tags is meant to indicate a problem, it defers the edit. By relying on the already well integrated change tag functionality, this can be easily used from a variety of sources. Problem tags are specified by tag managers, they trigger a deferral by default, but can be selectively prevented from doing so.

FlaggedRevs commits

• gerrit:218104 Main implementation
• gerrit:316957 Echo notification
• gerrit:315344 Change tags support

Related commits

The finished commits are struck out.

For simultaneous use of regular patrol

• gerrit:213582 Remove patrol links with JS when reviewing a revision
• gerrit:315109 Don't autopatrol autoreviewed users in protection-based configs

For easier reviewing

• gerrit:315145 Show log excerpt by default in review form

Required for change tags support

• gerrit:190656 Allow patrolling of tagged changes with minimalist RC patrol (this adds 'problem' tags)

Rollout

As agreed in the RFC on deferred changes, roll out should occur cautiously and progressively.

It is suggested to set an edit filter to defer only passively at first, check that this does not add excessively to the backlog, then it is possible to set it to defer actively if desired. To properly control the backlog, edit filters should be set to defer one by one or in small batches.

With bots and ORES, it is suggested to have two thresholds: one for passive defer and one (higher) for active defer; at the beginning active defer is not enabled and the passive defer is set to very high, then one checks that this does not add excessively to the backlog, and if it doesn't the threshold can become the active defer threshold, while at the same time the passive threshold can be set lower, and so on.