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. However, feel free to comment on the talk page.

Background

Problem statement as summarised by Dan Nessett. Although Dan summarised my points, it should be noted that he does not support this change. (to 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

Overview

There are currently a variety of groups. Their rights can be seen at Special:ListGroupRights. An analysis of each follows.

(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, it can be renamed to something more user friendly.

Also, the rights of the (all) group are unusual. The 'Use of the write API (writeapi)' and 'Mark as from Wikipedia (setwpfrom)' rights are activated for this group, even though they cannot actually edit pages.

Recommendation: I have renamed this to All visitors and Citizens below and redefined its rights.

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 it can be renamed.

Recommendation: I have renamed this Citizen below in line with Citizendium terminology as defined in the Charter. I have also modified its rights.

Autoconfirmed users

This group is promoted automatically when a userhas been registered for 30 days and performed 90 edits (numbers can be adjusted). It is like the 'karma' system that has been previously discussed, but is currently unused except for the ability to "Edit semi-protected pages", which is something we don't currently use.

Recommendation: I agree with the existance of this group, but the name is unhelpful and the rights need to be modified. I have further defined it below as Established Citizen.

emailconfirmed

This is supposed to be given to everyone who has confirmed their email address, however the configuration of CZ does not actually do this. If we wanted to make this work, we'd need the following line in LocalSettings.php: $wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;

Recommendation: As we don't confirm users until they have confirmed their email address anyway, this group would be identical to the Users group. Therefore I recommend we delete this group.

Wikieditors (shown as 'Editors')

This group is actually called 'wikieditors', but has been modified to display as 'Editors'. Despite the definitions of this group in LocalSettings.php and elsewhere, this group does not currently just contain Editors. According to old discussion list discussions this group originally was given to every registered user in order to allow them to edit the wiki. At some point this was changed, and now it is only given to people who apply as and are accepted as an Editor. This leads to a number of anomolies:

• Sandy Harris is not in this group and is not an Editor. This is logical.
• Howard C. Berkowitz is in this group and is an Editor. This is logical.
• John Stephenson is in this group despite not being an Editor. This is because he joined before the change.
• Chris Key is not in this group despite being an Editor. This is because the Editor promotion occured several months after registration.

This has caused confusion on at least two occasions . Also, all of the rights that an 'editor' has are duplicated from the 'User' group.

Recommendation: This group is completely illogical and needs removing. In my proposal it will be replaced by the Editor group which will only contain Editors as defined in the Charter. It's rights will be completely redefined.

EditInt

This group was created by Dan Nessett with the approval of Greg and Larry in order to allow me to fix Bug 49. I am currently the only member. The only function of this group is to allow me to edit pages within the MediaWiki namespace.

Recommendation: I agree with the existance of this group, but would suggest that the current name is unhelpful. A more descriptive name is suggested below (see Interface Developer).

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".

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 Citizen

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.

The current 'editor' group does not just contain Editors. We will need to clear this list (probably using direct database access) and refill the list (probably using a bot).

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.

Managing Editor

This group will only be given to the Managing Editor and his deputies. When their term ends, and they are not re-elected, this group will be removed from them. In the documentation below, unless otherwise specified, they will be given all powers given to the MC and the EC.

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 also be put into the Bot with Delete group. Further groups may be needed depending on what additional rights they need in order to complete their task, for example 'Bot with Promote User to Editor'. The rights for these groups would most likely be altered as the Bot policy is developed.

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

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 direct creation of new user accounts.

Technical Staff need this for creating Bot accounts. Management Committee need this for creating special purpose accounts (such as User:Approvals Manager. 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 rollbacks 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).

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

purge: allows purging a page without a confirmation step (URL parameter "&action=purge").

Purging forces the MediaWiki software and a page to rebuild itself; it is in this way not dissimilar to web browser refreshment. It is typically utilised to clear the cache and ensure that changes are immediately visible to everyone. Purging should be allowed by all 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

minoredit: allows marking an edit as 'minor'.

All Citizens can mark 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).

Only bots would require this, as only they are likely to make edits on a users talk page without needing to inform the user that there is a message.

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

The rate limit is the maximum number of actions allowed in a given number of seconds. All accounts should be held accountable to this to prevent technical difficulties

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.

This should not be given to anyone initially. In the event that we run into a problem regarding innocent people getting caught in an IP block then we should create a new group to put them in.

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).

We do not use the open proxy blocker currently, but this right would not be needed initially anyway. In the event that we run into a problem regarding innocent people getting caught in an open proxy block then we should create a new group to put them in.

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 ($wgUseRCPatrol must be true).

We do not use the recent changes patrol, therefore we do not require 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

autopatrol: automatically marks all edits by the user as patrolled ($wgUseRCPatrol must be true).

We do not use the recent changes patrol, therefore we do not require 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

apihighlimits: allows user to use higher limits for API queries

Only authorised bots should be using the higher 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

writeapi: controls access to the write API ($wgEnableWriteAPI must be true)

The write API is currently disabled, but all Citizens should be allowed to use the write API if we enable 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

suppressredirect: Allows moving a page without automatically creating a redirect.

Only bots require 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

siteadmin: allows locking and unlocking the database (which blocks all interactions with the web site except viewing). Deprecated by default.

Senior Technical Staff (very rarely) may need this in order to resolve technical issues or perform upgrades.

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

import: allows user to import one page per time from another wiki ("transwiki").

If this is required it should be done manually.

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

importupload: allows user to import several pages per time from XML files. This right was called 'importraw' in and before version 1.5.

Senior Technical Staff may occasionally require this right for restoring backups.

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

trackback: allows removal of trackbacks (if $wgUseTrackbacks is true).

Trackbacks are not enabled, and we therefore do not need 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

unwatchedpages: allows access to Special:Unwatchedpages, which lists pages that no user has watchlisted.

Established Citizens would find this useful.

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

setwpfrom: Allows the 'Content is from Wikipedia?' flag to be set on an article (CZ specific)

Anyone who can edit an article needs this right, so it is given to all 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

skipcaptcha: Removes the need for the user to see a CAPTCHA form (from Extension:ConfirmEdit)

Once a user is Established they should no longer see this. This extension is currently disabled, but the right should be added for if this needs to be turned on in case of spam attack.

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

checkuser: Grants users with the appropriate permission the ability to check user's IP addresses and other information (from Extension:CheckUser)

Required by Constables and EPA when approving accounts and for behaviour 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

confirmaccount: Allows access to Special:ConfirmAccounts, which is the page that is used to confirm pending account requests at Citizendium. (from Extension:ConfirmAccount)

Required by Constables for approving Author accounts, EPA members for approving Editor accounts and Technical Staff for approving Bot accounts.

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

setstatus: This was part of the original schema to mark a pages status as "from Wikipedia" or not. (CZ specific)

This right was part of the original coding, but has been confirmed by Greg Sabino Mullane to be useless. This right will be removed.

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

newslettermembers: Allows access to Special:NewsletterMembers, which is a list of people subscribed to the newsletter and the ability to unsubscribe people(for CZ specific Newsletter extension)

Only the EC and MC should have access to the Newsletter extension.

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

newslettermassmailer: Allows access to Special:NewsletterMassMailer which allows mass email to be sent to either all users subscribed to the newsletter, or all users registered on the wiki (for CZ specific Newsletter extension)

Only the EC and MC should have access to the Newsletter extension.

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

lookupcredentials: Allows access to Special:UserCredentials, which provides a users details that were provided upon registration (email address, biography, cv, etc.) (from Extension:ConfirmAccount)

May be needed by Constables, EC, MC and Ombudsman.

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

renameuser: Gives the right to rename users (from Extension:Renameuser)

All requests for renaming are processed by the Constabulary, so only they need 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

requestips: Adds IP address to the information on Special:UserCredentials (from Extension:ConfirmAccount)

May be needed by Constables, EC, MC and Ombudsman.

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.

References

• MediaWiki Manual:User rights

Feedback from other users

If you have specific feedback or criticism of the proposal, please post it in this area by clicking the button below. In order to not drag out differences of opinions I shall limit myself to only replying to each user once in this area, and only if I do not believe that it is something I have not covered in the main proposal. If you have questions or want a more prolonged discussion, please use the questions area. Feedback in this area should definitely be considered when deciding whether to support the proposal

The proposal is not yet finished. Please wait until this notice is removed before posting detailed feedback or criticism. In the mean time, please feel free to use the questions area for any comments or questions.

CLICK HERE TO ADD YOUR FEEDBACK

"Emergency reserve"

Do consider a "contingency" assignments of rights, for experienced Citizens who may no longer have a right ex officio, but might retain a privilege for which they have demonstrated competency, to be used only in situations such as the usual people with the right being unavailable or overloaded. Yes, I know this violates the Principle of Least Privilege and needs to be used with discretion.

For example, as current Secretary of the comatose Editorial Council, I have sysop, principally to be able to protect and unprotect. In practice, I use the delete privilege for my own articles, or, in a few cases, when either I've been asked to help in a situation where a great many articles needed to be deleted, overloading the Constables, or where I've been asked to unscramble badly confused metadata.

If the system permits, just as we've talked about using karma to rate-limit imports or moves, deletes might fall under karma. It would be helpful if it would be possible to restrict the granularity to articles that the Citizen created. A much smaller group, which I'll tentatively call "user support", might have more extensive privileges for situations such as metadata and misnaming cleanup.

Especially when we have a limited number of people, various support capabilities might be given on a case-by-case basis. For example, while I'm not doing day-to-day *IX administration, I will probably be doing so again, and in the past have even done kernel hacking for routers. Howard C. Berkowitz 21:31, 7 June 2010 (UTC)

The delete right is given to the following:

Right	Visitor	Citizen	Est. Cit.	Editor	MC	EC	Cop	Ombud.	Man. Ed.	EPA	Snr. Tech	I/face Dev	Larry	Bot	Bot /w Del	Works on Live CZ?
delete																Yes

My own feeling is that between the Constabulary, MC, EC, Ombudsman, Managing Editor and Senior Technical Staff there are enough people with the delete right to be able to help out the Constabulary in the rare event that they are unavailable or overloaded. The delete ability is powerful, and an automatic karma system does not seem appropriate. Of course, the MC may decide to officially create a 'User Support' role and assign people to it. This proposal allows for the MC to create new roles such as this at Creation of New Groups. --Chris Key 11:30, 8 June 2010 (UTC)

My suggestion is that "user support" or equivalent might be in supplementary notes, if the MC proper doesn't have people with the security and administration people to suggest it. I had missed that the EC and MC themselves would have the authority.

Incidentally, during the painful period in 2007, before my time, far more vandalism was caused with move than with delete. I've certainly spent a lot less time, in general system administration, restoring files than munged directory and naming structures.

Keep going; this is valuable thinking. Howard C. Berkowitz 14:16, 8 June 2010 (UTC)