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[1].
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: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
edit: allows editing unprotected pages.
All Citizens are allowed to edit pages.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
createpage: allows the creation of new pages (requires the edit right).
All Citizens are allowed to create new articles.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
createtalk: allows the creation of new talk pages (requires the edit right).
All Citizens are allowed to create new talk pages.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
move: allows renaming the titles of unprotected pages (requires the edit right).
This is a slightly more advanced tool, and it would be useful for Citizens to get to grips with CZ and it's policies before moving pages. Therefore, this is given to Established Citizens.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
movefile: allows renaming pages in the "File" namespace (requires the move right and $wgAllowImageMoving to be true).
The 'file' namespace is where images and videos are stored. This is a slightly more advanced tool, and it would be useful for Citizens to get to grips with CZ and it's policies before moving files. Therefore, this is given to Established Citizens.
Works on live CZ: No, requires v1.14 or later.
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
move-subpages: move subpages along with page (requires the move right).
Given the frequent use of subpages on CZ, this should be given to all who can 'move'.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
move-rootuserpages: can move root pages in the "User" namespace (requires the move right).
This would be moving people's actual User page. The only time that I can see this being needed is if a person's username is changed. This is dealt with by Constables, so only they have this right.
Works on live CZ: No, requires v1.14 or later.
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
createaccount: allows the creation of new user accounts.
Constables are responsible for approving authors. EPA members are responsible for approving Editors. Technical Staff are responsible for approving Bots. No other group requires this right.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
upload: allows the creation of new images and files.
All Citizens can upload new images, videos, etc.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
reupload: allows overwriting existing images and files (requires the upload right).
Overwriting an existing image could impact on a large number of articles. It is preferable that the user is familiar with CZ before doing such a thing. Therefore is given to Established Users only. However, see [#reupload-own]
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
reupload-own: allows overwriting existing images and files uploaded by oneself (requires the upload right).
Although overwriting someone elses image requires some knowledge of CZ, overwriting an image that you uploaded yourself should be avaliable to all Citizens as they will probably be aware of where it is used.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
upload_by_url: allows uploading by entering the URL of an external image (requires the upload right).
This is a conveniance tool only, and the same effect can be obtained by downloading the picture from the external URL and then uploading it. Therefore all Citizens have this right.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
editprotected: allows to edit protected pages (without cascading protection).
Not required. Everyone who needs to edit protected pages also needs to be able to protect them. Being able to protect a page also gives the power to edit protected pages. See #protect
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
delete: allows the deletion of pages. For undeletions, there is now the 'undelete' right, see below.
Constables require this for processing speedydelete requests. EC, MC and Ombudsman require this for dealing with content issues and for keeping policy pages in order. Senior Technical Staff require this for template maintainance and dealing with other technical issues. Bots that are approved for delete permission require this.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bigdelete: allows deletion of pages with larger than $wgDeleteRevisionsLimit revisions
Same as 'delete' above.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
deletedhistory: allows viewing deleted revisions, but not restoring.
Constables will require this in order to check a page before processing undeletion requests. EC, MC and Ombudsman will need to review these pages for dispute resolution and policy making.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
undelete: allows the undeletion of pages.
Everyone who can delete also needs to be able to undelete for the same reasons.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
browsearchive: allows prefix searching for titles of deleted pages through Special:Undelete.
Allows easy searching for pages that have been deleted. Give to everyone who has the undelete command.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mergehistory: allows access to Special:MergeHistory, to merge non-overlapping pages.
All wikimedia projects have this disabled as it introduces a security risk as revisions can be hidden secretly. Citizendium should leave it disabled.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
protect: allows locking a page to prevent edits and moves, and editing or moving locked pages.
Constables require this right in order to perform the approval process, and for behaviour management. It is likely that the MC and EC will want to protect the wording of any official policies they draw up, and therefore they need this right. The Ombudsman is also given this right for dispute resolution. Finally, Senior Technical Staff may need to edit protected pages when resolving technical bugs, particularly those involving templates.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
block: allows the blocking of IP addresses, CIDR ranges, and registered users. Block options include preventing editing and registering new accounts, and autoblocking other users on the same IP address.
Constables need this for obvious reasons. Senior Technical Staff require this in order to block users or bots that are consuming unacceptable amounts of system resources, or are causing other damage to the wiki. The MC are responsible for non-content issues, and therefore may need to block in some circumstances.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
blockemail: allows preventing use of the Special:Emailuser interface when blocking.
This is given to all users who can block.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
hideuser: allows hiding the user/IP from the block log, active block list, and user list when blocking.
This is a very powerful tool that hides (from all but those with this right) all traces that a user ever existed on the site. It would only be used in very specific circumstances after discussion amongst the MC. As a result, only the MC have this power. They may wish to restrict this further, and have just one or two nominated 'Compliance Officer' or similar. If this occurs, an extra group should be made for them and the MC should not gain this power.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
userrights: allows the use of the user rights interface, which allows the assignment or removal of all* groups to any user.
The Management Committee are overall responsible for officially implementing all appointments. Therefore they have full use of this right. Senior Technical Staff also require this in order to deal with technical issues. EPA members should have this, but it must be limited to adding (not removing) Editor rights only.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rollback: allows one-click reversion of edits.
This is similar to the 'undo' command found on article histories, but removes all prompts. It is therefore much quicker, but requires a careful hand. Given to Editors and the EC, who are most likely to deal with reverting edits. Given to Constables to deal with spam quickly. Given to Bots as this makes them more lightweight and reduces server load.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
markbotedits: allows rollback to be marked as bot edits
Bot edits can be filtered out of the recent changes list. This gives bots the right to mark their edits as bot edits.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
editinterface: allows editing the MediaWiki namespace, which contains interface messages.
Given to Senior Technical Staff and Interface Developers for technical improvements. Given to the MC as they may need to change copyright notices and similar.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
editusercssjs: allows editing *.css / *.js subpages of any user.
Given only to Senior Technical Staff. They will most likely only use this to help out a user who has broken their CZ experience by editing these subpages.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
deleterevision: allows deleting/undeleting information (revision text, edit summary, user who made the edit) of specific revisions
Given to Constables, Ombudsman, EC and MC only. When revision information is deleted like this, it may still be seen by people who have this right. This is a powerful tool and is to be used only in accordance with policies that the MC must create.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
suppressrevision: allows preventing deleted revision information from being viewed by sysops and prevents sysops from undeleting the hidden info. Previously known as hiderevision and nukerevision
Given to MC only. When revision information is deleted like this, it may still be seen by people who have this right - however Constables, Ombudsman and EC will not be able to see it. This is a very powerful tool and is to be used only in accordance with policies that the MC must create. They may wish to restrict this further, and have just one or two nominated 'Compliance Officer' or similar. If this occurs, an extra group should be made for them and the MC should not gain this power.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bot: hides edits from recent changes lists and watchlists by default (can optionally be viewed).
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
purge: allows purging a page without a confirmation step (URL parameter "&action=purge").
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
minoredit: allows marking an edit as 'minor'.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
nominornewtalk: blocks new message notification when making minor edits to user talk pages (requires minor edit right).
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
noratelimit: not affected by rate limits
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
ipblock-exempt: makes user immune to blocks applied to his IP address or a range (CIDR) containing it.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
proxyunbannable: makes user immune to the open proxy blocker, which is disabled by default ($wgBlockOpenProxies).
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
patrol: allows marking edits as legitimate
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
autopatrol: automatically marks all edits by the user as patrolled ($wgUseRCPatrol must be true).
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
apihighlimits: allows user to use higher limits for API queries
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
writeapi: controls access to the write API ($wgEnableWriteAPI must be true)
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
suppressredirect: Allows moving a page without automatically creating a redirect.
Works on live CZ: Yes
| Visitor | Citizen | Est. Cit. | Editor | MC | EC | Cop | Ombud. | Man. Ed. | EPA | Snr. Tech | I/face Dev | Larry | Bot | Bot /w Del |
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.