Jump to content

Requests for comment/Itemise protection

From mediawiki.org
Request for comment (RFC)
Itemise protection
Component General
Creation date
Author(s) Jarry1250
Document status in draft

Problem

[edit]

At the moment, we have flaky system where an article can either have one or zero edit protections, one or zero move protection, etc. but never more than one in any category.

The main issue arising from this (from a Wikimedia POV, at least) is that one cannot "surge" protection: that is to say, one cannot have a long-term background semiprotection in place, then layer in a short-term full protection during a particularly problematic period, because doing so would overwrite the semi protection.

This also prevents work on a system of pre-programmed future protections which may be useful for non-Wikimedia wikis.

Proposed changes

[edit]

A useful first step would be to add a pt_id field to protected_titles, since this allows records to be modified/deleted in an efficient manner.

More generally, I am working on a system where every existing protection in a given category is presented in a list, with checkboxes. Checking the box next to a record marks it for deletion.[nb 1] The existing system for adding protections is retained. It therefore becomes possible to surge protection as outlined above simply by unticking (or leaving unticked) the relevant checkbox.

Under this system, users must meet all restrictions to be able to edit the page. (This is not unexpected: the rhetoric of "Require..." makes it the route of least surprise.[nb 2])

By my calculations, the performance impact of such a change would be negligible. The proposed changes would leave the system for flagged protection (pending changes) unchanged.

I hereby request comment on this design.

Submitted by Jarry1250 at 19:44, 4 August 2011 (UTC)


  1. ↑ Wikimedia wikis would no doubt prefer the default to be all ticked, since this emulates existing behaviour.
  2. ↑ Unfortunately, a number of Wikimedia wikis, including the English Wikipedia, override this in a way that would have to be changed to be semantically valid under the new system.