Graded Fixity for MediaWiki
|
(English) This is an essay. It expresses the opinions and ideas of some Wikimedians but may not have wide support. This is not policy on Meta, but it may be a policy or guideline on other Wikimedia projects. Feel free to update this page as needed, or use the discussion page to propose major changes. |
 | This page is kept for historical interest. Any policies mentioned may be obsolete. If you want to revive the topic, you can use the talk page or start a discussion on the community forum. |
Rationale
[edit]The article protection facility has been a valuable tool to minimize the deleterious effects of petty vandalism, heated disputes, and careless errors.
However, its strictly binary nature -- an article is protected or not, an editor is a sysop with protection privileges or not -- may prove a limitation as the scale and features of a MediaWiki site grows. Content problems may occur in places, and at a rate, where a single category of fully-privileged editors cannot perform diligent maintenance. Or, in some domains the convention that a protected item should not be editted may prove less useful than the idea that only some edits should be prevented, and others still encouraged.
This is especially likely if article fields are available. Fields may have special meanings, communicating official information or metadata which should remain stable against most changes even as the rest of the article is volatile.
This is a proposal for an additional mechanism, analogous to the the protection mechansim, which can apply at the granularity of both articles and fields, and in multiple graded levels. The degree to which an article or field is resistant to edits is called "fixity".
Design
[edit]Overview
[edit]Any article, or article field, may have an integer 'fixity level' value associated with it. Additionally, all editor accounts have a 'fixity strength' value.
Any editor making changes must have a fixity strength equal to or higher than the fixity level of the article or field they are changing. Attempts to change articles or fields with a higher fixity level than the editors' fixity strength have no effect (though they may be logged for reference, as potential future improvements).
Any editor may also change the fixity level of an article or field to any level up to their own fixity strength, provided its prior fixity level was equal to or lower than their fixity strength.
The default fixity level for all items, and the default fixity strength for all editor accounts (and anonymous editors), is zero. Fixity strengths only rise as the MediaWiki community leaders decide to adopt use of this mechanism.
Ideally, fixity levels on items would rise when information becomes 'settled', or as an occasional defense against vandalism. Fixity strengths of editors would rise as their reputation for quality contributions grows. Special fields with always-high fixity could be used for certain system upkeep or procedural tasks.
Article Markup
[edit]A field's fixity level is established by a exponentiation-like notation, '^' plus the integer fixity level, appended to its name. Examples:
<fields> title^2 = A Brief History of Time author = Stephen Hawking </fields>
<field name="sysopNote^3">See [[Controversy History]] for background on this issue.</field>
The 'title' field in the first example has a fixity level of 2; the 'sysopNote' field has a fixity level of 3. Only editors with matching or higher fixity strengths can change (or delete) these fields.
An article's fixity level is established by defining a field within the article named 'articleFixity' which itself has the desired fixity level. (The value of the articleFixity field is irrelevant.) For example:
<fields> articleFixity^3 = defined </fields>
The enclosing article has an overall fixity level of 3; no one with a lower fixity strength may make any changes to the article.
When a submission is made that contains portions which, due to fixity levels exceeding the editor's fixity strength, cannot take effect, as much as is allowable takes effect. Any field whose value could not be changed reverts to its previous value and fixity, and any field that could not be deleted is restored, at the bottom of the article text if necessary.
Changes which are not accepted in this fashion could be logged for later review; making such a failed edit could be an encouraged way to suggest a change to editors with the strength to make the change.
Fixity in Nested Fields
[edit]Fixity levels always have the effect of preventing users with lower fixity strength from changing or removing fields set with a higher fixity level; they do not prevent addition of as-yet-unnamed fields. For example, consider the fields:
author.fullname^2 = John Doe author.affiliation^4 = SPECTRE
A user with fixity strength of 4 could change or delete any of the values, including possibly changing 'author' to a non-nested value, for example "author = John Doe". A user with fixity strength of 2 could only change or delete the 'author.fullname' field, but not do anything to affect the 'author.affiliation' field. Any user with any fixity level could add a new 'author.address' field.
Open issue: should there be a way to lock out additions by users below a certain fixity level? (Possibilities: require any new sibling fields to be of the same or higher fixity as the lowest existing nested field; define a special field indicating level required to add to the associative array; allow a fixity to be declared for the enclosing field like "author^2.affiliation^4".)
Open issue: should ordering of higher-fixity repeated values be preserved against lower-fixity edits? Consider for example:
contributor.0 = John Doe contributor.1 = Alan Smithee contributor.2^2 = Publius
How is the position of 'contributor.2' guaranteed against changing due to lower-fixity edits? Suggestion: guarantee an item will never move further down unless editted by someone of the same or higher fixity strength. So in the above, edits or deletes of 'contributor.0' and 'contributor.1' by users with fixity strength les than 2 could only move 'contributor.2' up, never down, in the ordering.
Editor Fixity Strength
[edit]Editor fixity strength is established by defining a field named 'editorFixity' within the editor's User page article, which itself has the desired fixity level. (The value of the editorFixity field is irrelevant.) For example:
<fields> editorFixity^3 = defined </fields>
The user whose page contains this field has a fixity strength of 3 for all their edits.
Note that anyone with a higher fixity strength may promote others up to their strength, or demote anyone of their strength or lower.
There need not be any other automated mechanisms for promoting or demoting an editor's fixity strength; the prevailing practices can be a consensus social convention enforced within the system. (System maintainers as usual have ultimate authority, deriving from their ability to make arbitary changes, such as assigning themselves the highest fixity strength.)
Alternative approach: The value of the editorFixity field is significant, and sets the user's fixity strength, but it cannot be higher than the fixity strength of the field itself. Thus "editorFixity^5 = 3" would be possible, and keep the user at strength 3 unless someone of strength 5 changed the value. However, "editorFixity^3 = 5" would only serve to give the user a fixity strength of 3, the lesser of the value or the field's own fixity.
Bootstrapping
[edit]A MediaWiki site wishing to adopt fixity might choose to assign initial editor fixity levels based on preexisting editor and administrator roles. Anonymous users could have a fixity strength of 0; registered users 1 and 2; sysops 3; bureaucrats and stewards 4; and the overall system governors/sponsors 5.
Alternatively, the fixity system could be orthogonal to existing roles. The developers or governors/sponsors could assign some set of seed editors high fixity strengths, and then let those editors promote other editors according to whatever conventions evolve.
Implementation and Database
[edit]To be determined.
Future Directions
[edit]Editors or groups of editors could be given non-standard fixity strengths with regard to specific articles or fields.
For example, an editor might be considered to have a high, or maximum, fixity strength over their own User page (except for the editorFixity field itself). Similarly, same-strength peers could be denied their regular fixity strength with regard to the others' editorFixity field to preclude peer-demotions.
A robot editor with a specific purpose could be given high, or maximum, fixity strength over a small set of fields it is tasked with maintaining.
A set of users tasked with verifying a particular set of fields, or particular article versions, could be given elevated fixity strength with regard to a special set of fields required for their task. (For example, 'lastVerifiedVersion'.)
References
[edit]This is an example of what MeatballWiki calls UseMod:AccessLevels, in the category of UseMod:HardSecurity. If fixity strengths vary based on temporary roles, then it takes on aspects of UseMod:FunctionalAccess and UseMod:PeerPrivilege.
The Help:User_levels system in the works for potential inclusion in MediaWiki 1.5 is an application of finer-grained access control to another set of system administration issues.