User:Chris Key/Sandbox/Proposal: Overhaul of user rights

IMPORTANT NOTICE

This is a draft proposal only, and very much a work in progress. Until this notice is removed I do not recommend following the proposal outlined in this document.

Also, feel free to comment on the talk page.

Background

Problem statement as summarised by Dan Nessett. Rewrite.

* The MW software is fully flexible and capable of supporting any group/rights architecture suitable for CZ.
* The existing access rights architecture does not quite fit the roles and responsibilities associated with various CZ governance positions. For example, Constables need to perform certain operations on the wiki, some of which require Sysop privileges, some of which do not. Some rights granted to Constables by virtue of their position as Sysops on the wiki are not useful to them in the pursuit of their Constable role. Creating an architecture that more closely follows the governance structure increases the transparency of access rights management and use at CZ. Furthermore, it is useful to implement fine granularity access control structures that give users only the rights they need and no more. This improves the overall security posture of CZ.
* When CZers without extra permissions observe terms like "Bureaucrat", "Sysop" and "Constable", they may become confused and think, for example, that the Sysop role is identified with the Constable role. They become frustrated when they contact a Sysop, asking them to perform a Constable function and are told that a Sysop does not have the organizational right to perform this function (even if they can technically perform it). Furthermore, arcane names like Bureaucrat or Dark Knight, due to their unfamiliarity or vaguely threatening connotations, may raise the level of discomfort of those unfamiliar with their technical meaning.
* Since the technology used by CZ to develop and deliver its content is not monolithic (i.e., it is implemented by various software systems that do not interact with each other), we should clarify roles within these software systems by using group names similar, if not identical, to the roles defined within CZ.

Current System

Current user group rights can be seen at Special:ListGroupRights.

Proposed System

Overview

The example document at User:Chris_Key/Sandbox/Userrights will be used only as a starting point for this section.

User rights groups

Discussion of which user groups should be created and the rationale behind each of them.

Automatic groups

All visitors and Citizens (previously known as '(all)')

This implied group covers everybody who uses Citizendium. It includes people who are not logged in as well as people who are logged in. This group is part of the core coding of MediaWiki and cannot be removed, however I would recommend renaming it on the list of group rights to "All visitors and Citizens".

All Citizens (previously known as 'Users')

This group is automatically given to every user account on Citizendium, and cannot be revoked. When a list of a user's groups is generated, this group is hidden. This group is part of the core coding of MediaWiki and cannot be removed, however I would recommend renaming it on the list of group rights to "All Citizens".

Established Citizens

This group is promoted automatically when a Citizen has been registered for 30 days and performed 90 edits, or some other combination of days and edits as specificed by the Management Committee. At this point it can be assumed that the Citizen is reasonably familiar with how Citizendium works, and can gain some additional helpful but more advanced tools. This has previously been discussed on the forums as a 'karma' system.

Groups specified in the Charter

Editor

This group will be given to an Editor once they have been approved by a member of the EPA (or other authorised person). Initially it will include very few extra rights, but should be put in place as a pre-emptive measure for future software development. For example, once the approval process is automated Editors can be given the right to nominate an article for approval. It will not be necessary to ever remove anyone from this group unless exceptional circumstances lead to their Editorship being revoked, or a policy is put in place that removes the Editorship from inactive Editors.

This group should not be confused with the current group called 'editor' (or in some other places, 'wikieditor'). Despite the definitions of this group in LocalSettings.php and elsewhere, this group does not currently just contain Editors.

Management Committee

This group will be given to current members of the Management Committee only. When their term ends, and they are not re-elected, this group will be removed from them.

Editorial Council

This group will be given to current members of the Editorial Council only. When their term ends, and they are not re-elected, this group will be removed from them.

Constable

This group will be given to serving members of the Constabulary only. If they resign or are removed from the post, this group will be removed from them.

Ombudsman

This group will only ever contain a single member, the Ombusdman. When their term ends, and they are not re-elected, this group will be removed from them.

Other groups

Editorial Personnel Administrator

Currently we have the position who are responsible for reviewing, accepting and rejecting Editor applications. This post is not mentioned in the Charter, but assuming the position is kept intact after the Charter is implemented, all EPAs will be put into this group. If they resign or are removed from the post, this group will be removed from them.

Senior Technical Staff

This group will be given to senior members of the Technical Staff. Which members it is given to would be at the discretion of the Management Committee (in liaison with the Technical Lead, if one exists) and would be given very selectively. It is likely that this group would correspond with, or be very similar to, the group of people given root server access. It is not necessary to give this power to every member of the Technical Staff. Membership to this group should be reviewed by the Management Committee annually, although it should be pointed out that a lack of activity on the wiki or forums does not automatically warrant removal from this group.

In general, these powers would not be used. They are given because Technical Staff may occasionally need to perform actions for technical reasons, such as blocking users or bots that are consuming unacceptable amounts of system resources, or undoing edits that put heavy strain on the servers. It should be noted that in an emergency anyone with root server access could give themselves any power, including those currently given to nobody. In the interests of transparency this should be avoided if at all possible, as no trace is left in any logs.

Interface Developer

This group is given to Citizens who need the ability to edit the MediaWiki namespace, which primarily includes system messages. Access to this group would need a good reason, which would be judged at the discretion of the Senior Technical Staff reporting to the Management Committee. An example of someone who in the past would have had sufficient reason to join this group is Caesar Schinas. He was given SysOp powers in order to work on the Upload Wizard and similar issues]. Another example would be for a user who wished to fix a bug like this. Membership to this group would be removed when the Citizen has been inactive for six months, or when they announce that they no longer wish to work on technical aspects of the project.

Founder

This group is given to Larry Sanger only. It would be given as a good-will gesture only, and can be revoked by the Management Committee at any time should they wish to do so. Initially the Founder group has been given the rights that Larry currently has access to. Unlike other groups, no further justification shall be presented as to why this user group is given rights.

Bot and Bot with Delete

Currently our Bot policy is not well developed, however it seems that bots will be run from specific accounts such as User:Housekeeping Bot. These accounts will be put into the Bot group to allow them access to the additional tools that they require. Some bots require the ability to delete pages. These shall be put into the Bot with Delete group.

Creation of New Groups

New groups are to be implemented at the discretion of the Management Committee, bearing in mind the following guidelines:

• No user should be put into an existing group unless they fulfil the criteria associated with it. It is better to create a new group with identical powers to a Constable than to put a non-Constable into the Constable's group.
• Every official role that requires special powers should be given a group with a descriptive name. Putting multiple roles into a single group is inadvisable.
• Every new group must be documented before being implemented.

Analysis of each specific right

Detailed analysis of each and every user right that is avaliable will go here, including a summary of who should get it.

read: allows viewing pages

Without this right it is not possible to view the content on any page. Therefore this should be yes for everyone.

Works on live CZ:

Visitor

Citizen

Est. Cit.

Editor

MC

EC

Cop

Ombud.

Man. Ed.

EPA

Snr. Tech

I/face Dev

Larry

Bot

Bot /w Del

   *  View the abuse log (abusefilter-log)
   *  View detailed abuse log entries (abusefilter-log-detail)
   *  Modify abuse filters (abusefilter-modify)
   *  Modify abuse filters with restricted actions (abusefilter-modify-restricted)
   *  View private data in the abuse log (abusefilter-private)
   *  Revert all changes by a given abuse filter (abusefilter-revert)
   *  View abuse filters (abusefilter-view)
   *  View abuse filters marked as private (abusefilter-view-private)
   *  Use higher limits in API queries (apihighlimits)
   *  Edit semi-protected pages (autoconfirmed)
   *  Have one's own edits automatically marked as patrolled (autopatrol)
   *  Delete pages with large histories (bigdelete)
   *  Block other users from editing (block)
   *  Block a user from sending e-mail (blockemail)
   *  Be treated as an automated process (bot)
   *  Search deleted pages (browsearchive)
   *  Lock or hide global account (centralauth-lock)
   *  Merge their account (centralauth-merge)
   *  Suppress global account (centralauth-oversight)
   *  Unmerge global account (centralauth-unmerge)
   *  Manage central notices (centralnotice-admin)
   *  Translate central notices (centralnotice-translate)
   *  Check user's IP addresses and other information (checkuser)
   *  View the checkuser log (checkuser-log)
   *  Save books as community page (collectionsaveascommunitypage)
   *  Save books as user page (collectionsaveasuserpage)
   *  Create new user accounts (createaccount)
   *  Create pages (which are not discussion pages) (createpage)
   *  Create discussion pages (createtalk)
   *  Delete pages (delete)
   *  View deleted history entries, without their associated text (deletedhistory)
   *  View deleted text and changes between deleted revisions (deletedtext)
   *  Delete and undelete specific revisions of pages (deleterevision)
   *  Edit pages (edit)
   *  Edit the user interface (editinterface)
   *  Edit other users' CSS and JS files (editusercssjs)
   *  Make global blocks (globalblock)
   *  Bypass global blocks (globalblock-exempt)
   *  Disable global blocks locally (globalblock-whitelist)
   *  Edit membership to global groups (globalgroupmembership)
   *  Manage global groups (globalgrouppermissions)
   *  Remove global blocks (globalunblock)
   *  Hide revisions from administrators (hiderevision)
   *  Block a username, hiding it from the public (hideuser)
   *  Import pages from other wikis (import)
   *  Import pages from a file upload (importupload)
   *  Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)
   *  Mark rolled-back edits as bot edits (markbotedits)
   *  Mark edits as minor (minoredit)
   *  Move pages (move)
   *  Move root user pages (move-rootuserpages)
   *  Move pages with their subpages (move-subpages)
   *  Move files (movefile)
   *  Not have minor edits to discussion pages trigger the new messages prompt (nominornewtalk)
   *  Not be affected by rate limits (noratelimit)
   *  Mass delete pages (nuke)
   *  Override the spoofing checks (override-antispoof)
   *  Export pages including linked pages up to a depth of 5 (override-export-depth)
   *  View a previously hidden revision (oversight)
   *  Mark others' edits as patrolled (patrol)
   *  Change protection levels and edit protected pages (protect)
   *  Bypass automatic blocks of proxies (proxyunbannable)
   *  Purge the site cache for a page without confirmation (purge)
   *  Read pages (read)
   *  Rename users (renameuser)
   *  Overwrite existing files (reupload)
   *  Override files on the shared media repository locally (reupload-shared)
   *  Quickly rollback the edits of the last user who edited a particular page (rollback)
   *  Send e-mail to other users (sendemail)
   *  Lock and unlock the database (siteadmin)
   *  Perform captcha triggering actions without having to go through the captcha (skipcaptcha)
   *  View private logs (suppressionlog)
   *  Not create redirects from source pages when moving pages (suppressredirect)
   *  Review and restore revisions hidden from administrators (suppressrevision)
   *  Override the title blacklist (tboverride)
   *  Bypass automatic blocks of tor exit nodes (torunblocked)
   *  Submit a trackback (trackback)
   *  Undelete a page (undelete)
   *  View a list of unwatched pages (unwatchedpages)
   *  Upload files (upload)
   *  Upload files from a URL (upload_by_url)
   *  Edit all user rights (userrights)
   *  Edit user rights of users on other wikis (userrights-interwiki)
   *  Use of the write API (writeapi)

Summary

Create a table similar to that seen at User:Chris_Key/Sandbox/Userrights.

Implementation

Include instructions on how to implement this, including modifications to LocalSettings.php for implementing the new setup and removing the old setup.

Testing

Attempt to set up a clone on shared hosting with a full test of the proposed system. Failing that, conduct a thorough test on my personal clone.

References

• MediaWiki Manual:User rights