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
Citizendium's Wiki runs on standard MediaWiki software[1]. This software provides a permissions system which allows users to be added to multiple user groups, and each of these user groups to be able to do a variety of things. By default MediaWiki sets up a number of standard user groups such as 'User', 'SysOp' and 'Bureaucrat', and gives them a standard set of user rights. Citizendium still uses these groups, although the rights have been modified slightly. CZ technical staff have also added a few extra user groups such as 'Dark Knight', 'Linnaeus' and 'Wikieditor' to allow for some functions to be given to just a limited number of people. Although these groups are the default groups, MediaWiki fully supports the ability to add, remove and modify user groups. The only groups that cannot be removed is 'Users', however it can be modified.
Citizendium's Forum runs on Simple Machines Forum (SMF) software[2]. This software provides a permissions system which also allows users to be added to multiple user groups, and each of these user groups to be able to do a variety of things. By default SMF sets up one standard user group called 'Administrator', a title which is shown underneath the name of the user when they make a post. Citizendium only uses this default group, however SMF fully supports the ability to add, remove and modify user groups.
Citizendium's Charter and policies define a number of roles, such as 'Citizen', 'Editor', 'Constable', 'Management Committee', 'Editorial Council' and 'Ombudsman'. In addition there are a number of roles in Citizendium that are not mentioned in the Charter, such as 'Bot', 'Technical Staff' and 'Editorial Personnel Administrator'.
There is currently little correlation between the roles on the wiki, the roles on the forum, and the roles that actually exist in Citizendium's Charter and policies. For example:
- A Constable is given Administrator status on the forums and SysOp status on the wiki. Some of them are also given Linnaeus and/or Bureaucrat status on the wiki.
- Senior members of the technical staff are also given Administrator status on the forums and SysOp status on the wiki. Some of them are also given Bureaucrat and/or Dark Knight status on the wiki.
- Wikieditor status is given out according to a seemingly random basis that can be tracked down to a few technical and historical issues. It does not correlate to Editor status.
- New groups are created on an ad-hoc basis, such as the EditInt group which was created when a junior member of the technical team needed to fix a bug requiring the editinterface permission.
Due to this, there have been occasions where a Constable has gone to do something and has found he needs Bureaucrat status, but didn't actually know what that was[3]. There have also been occasions where a new Citizen contacted a SysOp thinking they were a Constable, when in fact they were a member of the Technical Team. Also, there have been concerned Citizens wondering why the list of people marked as 'editor' did not correlate to the actual list of Editors[4]. When I myself first joined Citizendium, I saw the word 'Administrator' underneath a Constables name on the forums. When I later saw another (non-Constable) user with the word 'Administrator' there, I initially thought that they were also a Constable. Few people actually understand what a 'Dark Knight' or a 'Linnaeus' is. This goes against the Charter's stated aim of transparency.
By bundling various roles into the same group some policies are ambiguous. For example, the Approval Process policy states that any 'sysop' may carry out the process, however it is generally considered a Constables job. Could someone like Caesar Schinas, who was given SysOp in order to perform some maintainance on the subpages system and the upload wizard, carry out the process? According to the policy he could, and he certainly has the technical powers necessary, yet I am sure that the person who gave him SysOp powers did not intend this.
In addition, using grouping roles together and giving them all permissions such as those given to SysOps lead to users having more powers than they actually need. For example, a Constable can currently edit the User Interface despite this not being part of their job description. The Linnaeus group needed to be created to allow Constables the ability to rename users without giving it to other SysOps. Caesar Schinas has the power to block people, and the only thing stopping him is trust. Giving a new permission to the SysOp role requires a lot of thought, as you have to take into account that it will give the permission to a wide variety of people including Constables, Technical Staff, EC members and others. From a security standpoint this is obviously a bad thing, especially as Citizendium grows and larger numbers of people need to be kept track of.
There is also no policy for removing any permissions. If a Constable steps down should they lose their SysOp powers, or should they keep them in case they need them? There are certainly a large number of ex-Constables who still have these powers. Does the answer change if they are also a member of the technical staff, and haven't resigned from that position?
One last problem is that the rights themselves are duplicated between groups. For example:
- The '(all)' user group covers everyone, whether they are logged in or not. Obviously they need the right to read pages, and as such they are given the permission called 'read'.
- The user group called 'user' covers everyone who is logged in. They have also been given the 'read' permission, even though they inherit it from the '(all)' group. They now have it twice.
- The user group called 'sysop' is given to several groups of people. They have also been given the 'read' permission, even though they inherit it from the '(all)' group AND the 'user' group. They now have it three times.
- The user group called 'bureaucrat' is given to a few people, and every single one of them is also a SysOp. It is almost unimaginable that a user will ever be a bureaucrat without also being a SysOp. Bureaucrats have also been given the 'read' permission, even though they inherit it from the '(all)' group AND the 'user' group AND they have it from being a SysOp. They now have it four times!
This redundancy doesn't cause any technical issues, however it does make Special:ListGroupRights quite difficult to read. With a well planned user group system, inheritance will become obvious and avoidable redundancies will not occur.
My proposal is to completely revamp the entire system. Roles in Citizendium will be reflected on the wiki software and the forum software. A Constable will be given 'Constable' status on the wiki, and 'Constable' status on the forum. A member of the Management Committee will be given the 'Management Committee' status on the wiki, and 'Management Committee' status on the forum. When either of these leave their position, the right will simply be taken away from them. Someone who is an Editor, a Constable and a senior member of the Technical Staff will be given put in the 'Editor', 'Constable' and 'Senior Technical Staff' groups. If they then resign as Constable, the 'Constable' group will be removed but the others will remain.
The main advantages of this proposal are:
- All of the groups will have descriptive names
- It will be easy to know which groups to put a member in, and when to remove them
- It will be easy to see who is in which groups and why
- Viewing Special:ListGroupRights will give a very transparent view of who can do what
- We will be able to automatically generate lists of Constables, Editors, Technical Staff, etc.
- It will be easy to give a new power to a group, without having to consider all the different types of people that you are also giving the power to
- When you see a post from someone on the forum, you will know if they are a Constable or a member of the Technical Staff
- A Constable will just be a Constable... not a Constable and a Sysop and a Linnaeus and an Administrator.
- When we develop future extensions, we will be able to give new rights to various groups without having to create new groups. For example, a new extension to automate the approval process will give the ability to nominate an article to those in the 'Editor' group, and the ability to carry out the approval to those in the 'Constable' group.
There are some disadvantages, although I believe them to be minor:
- Some extensions assume that there is a SysOp and/or a Bureaucrat group, and therefore create them so they can give them permissions. However, one line at the end of the LocalSettings.php file can remove these groups again. The permissions can then be given to the groups that we want to have them.
- Some areas of the MediaWiki manual and other documentation refer to SysOps and Bureaucrats. The reader would have to bear in mind that we have customised the permissions system and that these groups no longer exist. However, due to the fact that these groups can be customised, most of the MediaWiki documentation references specific rights such as 'block' or 'delete' rather than groups.
- The Feedback from other users section at the bottom of this page may contain other disadvantages that I have not considered. Please be sure to read this feedback when considering this proposal.
Current System
There are currently a variety of groups. Their rights can be seen at Special:ListGroupRights. An analysis of each follows.
Current MediaWiki User Rights Groups
(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.
Bots
The Bot group is used for Bot accounts, as defined in the CZ:Bot policy that is under development. These accounts need special rights in order to hide their large quantities of edits from the recent changes page, skip things like the CAPTCHA blocks, and perform edits at a higher rate than a human can.
Recommendation: Keep the current group but redefine its rights slightly. Make additional sub-groups for those bots that require special permissions such as Delete.
Sysops
SysOp is a default group included with the MediaWiki software, however it can be removed by adding the following line to LocalSettings.php: unset($wgGroupPermissions['sysop']); It is currently Citizendium's catch-all user group for 'those who require extra powers'. Historically this has included Constables, Senior Technical Staff, assistants to the technical staff, the Secretary to the Editorial Council, CZ's Founder, co-coordinator of the Wikiconverting group and has also been given to anyone else who needs the extra powers, for example Caesar Schinas who was given SysOp in order to perform some maintainance on the subpages system and the upload wizard. For some people I have been unable to find any reason whatsoever, although I am sure there must have been a reason at the time. Because all of these groups of people have all been put into the big 'SysOp' group, it becomes difficult to know why they were put there, or when they should be removed.
The other big problem with the SysOp group is for most of the people it is given to, it is more powers than are necessary. The co-coordinator of the Wikiconverting group does not need the power to block people. Constables do not need the power to edit the user interface. Technical Staff do not need to be able to look up people's email addresses. If it becomes obvious that a Constable needs a power they do not have, giving it to the SysOp group means that lots of extra people have this power also. The alternative is to create a new group and just add the Constables to it, but if we are going to do that why not put all the constables powers in a separate group?
As SysOp does not correlate to any particular role, some users may become confused when seeing the list. This has lead to some SysOps putting a notice on their user pages stating that although they are SysOps, they are not Constables.
Recommendation: Delete this group entirely. Each role should have its own user group with its own powers. This will allow us to know why people have these powers, and keep a tighter cap on exactly which powers they have.
Bureaucrats
Bureaucrat is a default group included with the MediaWiki software, however it can be removed by adding the following line to LocalSettings.php: unset($wgGroupPermissions['bureaucrat']); On CZ this has been given to the most trusted people who need it. Historically this has been the Editor-in-Chief, the Managing Editor, Senior Technical Staff, the Chief Constable and the Assistant Chief Constable. All of these people are also SysOps. The purpose of the bureaucrat role is primarily the ability to promote users into and demote users from other user groups. They also have the ability to use the newsletter extension and to rename users.
Bureaucrat does not relate to any role in the CZ charter or its policies. It also takes a little bit of digging in order to find out why people have been given the power, and there are no criteria for its removal.
Recommendation: Delete the group completely. Spread the powers into the groups that need them that are actually defined in CZ terminology.
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 messages[5] 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 [6]. 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).
Dark Knight
The 'Dark Knight' group is for users who have the 'nukerevision' power. This is a very powerful permission that allows a revision of a page to be hidden completely, so that the only people who can see it are others who have 'nukerevision'. The only people that have this power are the Editor-in-Chief, the Chief Constable, the Technical Lead and the ex-Technical Director.
The name of this group is completely inappropriate for a professional and acadamic site like Citizendium.
Nukerevision no longer exists. It has been replaced by deleterevision and suppressrevision. The deleterevision hides the revision from anyone but those who have deleterevision or suppressrevision. Suppressrevision goes one step further and hides the revision from anyone but those who have suppressrevision.
Recommendation: Delete this group entirely. Give deleterevision to Constables, EC, MC, Ombudsman and Managing Editor. Give Suppressrevision to the MC only. Policies should be drawn up to govern usage of these powers.
EPAs
This user group was created for Editorial Personnel Administrators who are in charge of reviewing Editor applications. The special group allows them to see applications.
Recommendation: Keep this group, but expand it's name to Editorial Personnel Administrators (CZ policy is to avoid abbreviations where possible). Revise their rights slightly, as they will need the ability to promote people to the new 'Editor' group.
Linnaeus
This group was created for Constables who have the ability to rename users. It's only purpose it to allow them to rename users. It's name is unusual, and doesn't in any way describe what it does.
Recommendation: Remove this group entirely. The new 'Constables' group will have the power to rename users.
Current Simple Machines Forum User Groups
Administrator
This is the only special group on the SMF forums. It is a default group that cannot be removed, and has all powers on the forum. It is currently given to anyone who needs special powers, such as Constables or Technical Staff. It causes the word 'Administrator' to appear under the users name when they post, therefore causing confusion for newcomers who may think that everyone with the word 'Administrator' has the same role in CZ.
Recommendation: Rename this group to 'Snr Tech Staff'. Move all non-Tech Staff out of this group and put them in new groups with names to match the role, eg Constable or Founder.
Proposed System
My proposal is to completely remove the current user groups from both the wiki and the forum software. These should be replaced with CZ-role specific groups as detailed below.
Proposed MediaWiki User Rights Groups
All current groups should be removed. To replace them, the following groups should be created:
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 Editorial Personnel Administrators 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
What follows is an analysis of each permission taken from the MediaWiki manual[7] as well as each permission that is defined in an extension that is used by Citizendium. For each I have given a description of what the permission does, followed by an analysis of which user groups I believe should be given the permission. Some of these are a matter of opinion or policy, and I am open to change on these. A couple of permissions are marked as needing a version of the MW software that is higher than the one used on Citizendium. I have treated these permissions as any other, as the long-term plan is to upgrade the software to the most current version.
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 NOT have this, instead we add the following line to LocalSettings.php: $wgAddGroups['sysop'] = array( 'Editor' );. This limits them 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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
editprotectedtemplates: allows editing of protected template
Some templates, such as the {{subpages}} template, are protected to prevent accidental damage to templates that control user interface. The ability to edit these templates should be given to Interface Designers who may need to edit them in the line of their work. In order to do this, we will need to add the line $wgRestrictionLevels[] = 'editprotectedtemplates'; to LocalSettings.php and add this right. We also need to edit MediaWiki:Protect-level-editprotectedtemplates to give it a more user friendly text. This right is also given to those who have the 'protect' 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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Summary of Rights Given to Each User Group
| 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? |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| read |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| edit |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| createpage |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| createtalk |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| move |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| movefile |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v1.14+ |
| move-subpages |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| move-rootuserpages |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v1.14+ |
| createaccount |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| upload |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| reupload |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| reupload-own |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| upload_by_url |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| editprotected |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| delete |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| bigdelete |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| deletedhistory |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| undelete |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| browsearchive |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| mergehistory |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| protect |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| block |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| blockemail |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| hideuser |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| userrights |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| rollback |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| markbotedits |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| editinterface |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| editusercssjs |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| deleterevision |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| suppressrevision |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| bot |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| purge |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| minoredit |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| nominornewtalk |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| noratelimit |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| ipblock-exempt |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| proxyunbannable |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| patrol |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| autopatrol |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| apihighlimits |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| writeapi |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| suppressredirect |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| siteadmin |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| import |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| importupload |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| trackback |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| unwatchedpages |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| setwpfrom |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| skipcaptcha |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| checkuser |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| confirmaccount |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| setstatus |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| newslettermembers |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes
|
| newslettermassmailer |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| lookupcredentials |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| renameuser |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| requestips |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
| editprotectedtemplates |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes
|
Proposed Simple Machines Forum User Groups
The actual rights for the SMF forum software do not really need to be altered. What does need altering is the display of 'Administrator' underneath the name of a person who has 'special powers' on the forum. I therefore propose the following that we create groups that are identical to the Administrator group but have the following names:
- Constable
- Technical Staff
- Founder
These cover everyone who is active that needs special powers on the forum.
There are also four possibilities that could be implemented using SMF user groups. The following do not form part of my recommendation, and are simply a notification of options available:
Citizen group
According to forum rules, non-Citizens may use only the "Non-member discussion" and "General help" boards. It would be possible to set up a 'Citizen' group that allows posting to other forums, and therefore non-Citizens would not be able to post in these forums. However, this would require the Constable to check if a new user is a Citizen, and if so promote them to the new group. The overhead is probably not worth the reward.
Reading by visitors
Currently it is possible to read each forum without being logged in. If some of the forums are deemed more sensitive, it is possible to restrict viewing of these forums to registered users only.
Other special groups
Occasionally there has been need to create a board that is only allowed to be posted in by certain members, for example the board called 'CHARTER DRAFT COMMITTEE MEMBERS ONLY'[8]. It is possible to create new groups for occasions such as this, and only allow members of those groups to post in them.
Replacement of private mailing lists
If it is wanted, private mailing lists (such as the one used by constables) could be replaced with forums that cannot be viewed or posted in by anyone who is not in certain groups.
Implementation
Include instructions on how to implement this, including modifications to LocalSettings.php for implementing the new setup and removing the old setup.
Modifications to the MediaWiki Configuration
Create the following MediaWiki namespace pages
- MediaWiki:setwpfrom - Mark articles as having content from Wikipedia.
- MediaWiki:confirmaccount - Confirm and reject pending account requests.
- MediaWiki:editprotectedtemplates - Edit templates that have been protected.
- MediaWiki:lookupcredentials - View a user's registration details such as email address, biography and CV.
- MediaWiki:requestips - View the IP address that a user registered with.
- MediaWiki:newslettermassmailer - Send emails to all members subscribed to the Newsletter, or to all registered members.
- MediaWiki:newslettermembers - Maintain the list of members subscribed to the Newsletter.
- MediaWiki:userrights-addeditor - Promote users to Editor.
- MediaWiki:protect-level-editprotectedtemplates - Protect a template.
- MediaWiki:restriction-level-editprotectedtemplates Full protected template
Modify the following MediaWiki namespace pages
- MediaWiki:protect-level-sysop - Protect an article
Add this to LocalSettings.php
# read - allows viewing pages$wgGroupPermissions['*']['read'] = true;
# edit - allows editing unprotected pages.$wgGroupPermissions['user']['edit'] = true;
# createpage - allows the creation of new pages (requires the edit right).$wgGroupPermissions['user']['createpage'] = true;
# createtalk - allows the creation of new talk pages (requires the edit right).$wgGroupPermissions['user']['createtalk'] = true;
# move - allows renaming the titles of unprotected pages (requires the edit right).$wgGroupPermissions['EstablishedCitizen']['move'] = true;
# movefile - allows renaming pages in the "File" namespace (requires the move right and $wgAllowImageMoving to be true)./* Requires v1.14 or later.$wgGroupPermissions['EstablishedCitizen']['movefile'] = true;*/
# move-subpages - move subpages along with page (requires the move right).$wgGroupPermissions['EstablishedCitizen']['move-subpages'] = true;
# move-rootuserpages - can move root pages in the "User" namespace (requires the move right)./* Requires v1.14 or later.$wgGroupPermissions['Constable']['move-rootuserpages'] = true;*/
# createaccount - allows the direct creation of new user accounts.$wgGroupPermissions['ManagementCommittee']['createaccount'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['createaccount'] = true;
# upload - allows the creation of new images and files.$wgGroupPermissions['user']['upload'] = true;
# reupload - allows overwriting existing images and files (requires the upload right).$wgGroupPermissions['EstablishedCitizen']['reupload'] = true;
# reupload-own - allows overwriting existing images and files uploaded by oneself (requires the upload right).$wgGroupPermissions['user']['reupload-own'] = true;
# upload_by_url - allows uploading by entering the URL of an external image (requires the upload right).$wgGroupPermissions['user']['upload_by_url'] = true;
# editprotected - allows to edit protected pages (without cascading protection).// Permission not assigned to any user group
# delete - allows the deletion of pages. For undeletions, there is now the 'undelete' right, see below.$wgGroupPermissions['ManagementCommittee']['delete'] = true;$wgGroupPermissions['EditorialCouncil']['delete'] = true;$wgGroupPermissions['Constable']['delete'] = true;$wgGroupPermissions['Ombudsman']['delete'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['delete'] = true;$wgGroupPermissions['Founder']['delete'] = true;$wgGroupPermissions['BotWithDelete']['delete'] = true;
# bigdelete - allows deletion of pages with larger than $wgDeleteRevisionsLimit revisions$wgGroupPermissions['ManagementCommittee']['bigdelete'] = true;$wgGroupPermissions['EditorialCouncil']['bigdelete'] = true;$wgGroupPermissions['Constable']['bigdelete'] = true;$wgGroupPermissions['Ombudsman']['bigdelete'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['bigdelete'] = true;$wgGroupPermissions['Founder']['bigdelete'] = true;$wgGroupPermissions['BotWithDelete']['bigdelete'] = true;
# deletedhistory - allows viewing deleted revisions, but not restoring.$wgGroupPermissions['ManagementCommittee']['deletedhistory'] = true;$wgGroupPermissions['EditorialCouncil']['deletedhistory'] = true;$wgGroupPermissions['Constable']['deletedhistory'] = true;$wgGroupPermissions['Ombudsman']['deletedhistory'] = true;$wgGroupPermissions['Founder']['deletedhistory'] = true;
# undelete - allows the undeletion of pages.$wgGroupPermissions['ManagementCommittee']['undelete'] = true;$wgGroupPermissions['EditorialCouncil']['undelete'] = true;$wgGroupPermissions['Constable']['undelete'] = true;$wgGroupPermissions['Ombudsman']['undelete'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['undelete'] = true;$wgGroupPermissions['Founder']['undelete'] = true;$wgGroupPermissions['BotWithDelete']['undelete'] = true;
# browsearchive - allows prefix searching for titles of deleted pages through Special:Undelete.$wgGroupPermissions['ManagementCommittee']['browsearchive'] = true;$wgGroupPermissions['EditorialCouncil']['browsearchive'] = true;$wgGroupPermissions['Constable']['browsearchive'] = true;$wgGroupPermissions['Ombudsman']['browsearchive'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['browsearchive'] = true;$wgGroupPermissions['Founder']['browsearchive'] = true;$wgGroupPermissions['BotWithDelete']['browsearchive'] = true;
# mergehistory - allows access to Special:MergeHistory, to merge non-overlapping pages.// Permission not assigned to any user group
# protect - allows locking a page to prevent edits and moves, and editing or moving locked pages.$wgGroupPermissions['ManagementCommittee']['protect'] = true;$wgGroupPermissions['EditorialCouncil']['protect'] = true;$wgGroupPermissions['Constable']['protect'] = true;$wgGroupPermissions['Ombudsman']['protect'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['protect'] = true;$wgGroupPermissions['Founder']['protect'] = true;
# 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.$wgGroupPermissions['ManagementCommittee']['block'] = true;$wgGroupPermissions['Constable']['block'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['block'] = true;$wgGroupPermissions['Founder']['block'] = true;
# blockemail - allows preventing use of the Special:Emailuser interface when blocking.$wgGroupPermissions['ManagementCommittee']['blockemail'] = true;$wgGroupPermissions['Constable']['blockemail'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['blockemail'] = true;$wgGroupPermissions['Founder']['blockemail'] = true;
# hideuser - allows hiding the user/IP from the block log, active block list, and user list when blocking.$wgGroupPermissions['ManagementCommittee']['hideuser'] = true;
# userrights - allows the use of the user rights interface, which allows the assignment or removal of all* groups to any user.$wgGroupPermissions['ManagementCommittee']['userrights'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['userrights'] = true;$wgGroupPermissions['Founder']['userrights'] = true;
# rollback - allows one-click reversion of edits.$wgGroupPermissions['Editor']['rollback'] = true;$wgGroupPermissions['EditorialCouncil']['rollback'] = true;$wgGroupPermissions['Constable']['rollback'] = true;$wgGroupPermissions['Bot']['rollback'] = true;
# markbotedits - allows rollback to be marked as bot edits$wgGroupPermissions['Bot']['markbotedits'] = true;
# editinterface - allows editing the MediaWiki namespace, which contains interface messages.$wgGroupPermissions['ManagementCommittee']['editinterface'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['editinterface'] = true;$wgGroupPermissions['InterfaceDeveloper']['editinterface'] = true;$wgGroupPermissions['Founder']['editinterface'] = true;
# editusercssjs - allows editing *.css / *.js subpages of any user.$wgGroupPermissions['SeniorTechnicalStaff']['editusercssjs'] = true;
# deleterevision - allows deleting/undeleting information (revision text, edit summary, user who made the edit) of specific revisions$wgGroupPermissions['ManagementCommittee']['deleterevision'] = true;$wgGroupPermissions['EditorialCouncil']['deleterevision'] = true;$wgGroupPermissions['Constable']['deleterevision'] = true;$wgGroupPermissions['Ombudsman']['deleterevision'] = true;$wgGroupPermissions['Founder']['deleterevision'] = true;
# 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$wgGroupPermissions['ManagementCommittee']['suppressrevision'] = true;
# bot - hides edits from recent changes lists and watchlists by default (can optionally be viewed).$wgGroupPermissions['Bot']['bot'] = true;
# purge - allows purging a page without a confirmation step (URL parameter "&action=purge").$wgGroupPermissions['user']['purge'] = true;
# minoredit - allows marking an edit as 'minor'.$wgGroupPermissions['user']['minoredit'] = true;
# nominornewtalk - blocks new message notification when making minor edits to user talk pages (requires minor edit right).$wgGroupPermissions['Bot']['nominornewtalk'] = true;
# noratelimit - not affected by rate limits// Permission not assigned to any user group
# ipblock-exempt - makes user immune to blocks applied to his IP address or a range (CIDR) containing it.// Permission not assigned to any user group
# proxyunbannable - makes user immune to the open proxy blocker, which is disabled by default ($wgBlockOpenProxies).// Permission not assigned to any user group
# patrol - allows marking edits as legitimate ($wgUseRCPatrol must be true).// Permission not assigned to any user group
# autopatrol - automatically marks all edits by the user as patrolled ($wgUseRCPatrol must be true).// Permission not assigned to any user group
# apihighlimits - allows user to use higher limits for API queries$wgGroupPermissions['Bot']['apihighlimits'] = true;
# writeapi - controls access to the write API ($wgEnableWriteAPI must be true)$wgGroupPermissions['user']['writeapi'] = true;
# suppressredirect - Allows moving a page without automatically creating a redirect.$wgGroupPermissions['Bot']['suppressredirect'] = true;
# siteadmin - allows locking and unlocking the database (which blocks all interactions with the web site except viewing). Deprecated by default.$wgGroupPermissions['SeniorTechnicalStaff']['siteadmin'] = true;
# import - allows user to import one page per time from another wiki ("transwiki").// Permission not assigned to any user group
# importupload - allows user to import several pages per time from XML files. This right was called 'importraw' in and before version 1.5.$wgGroupPermissions['SeniorTechnicalStaff']['importupload'] = true;
# trackback - allows removal of trackbacks (if $wgUseTrackbacks is true).// Permission not assigned to any user group
# unwatchedpages - allows access to Special:Unwatchedpages, which lists pages that no user has watchlisted.$wgGroupPermissions['EstablishedCitizen']['unwatchedpages'] = true;
# setwpfrom - Allows the 'Content is from Wikipedia?' flag to be set on an article (CZ specific)$wgGroupPermissions['user']['setwpfrom'] = true;
# skipcaptcha - Removes the need for the user to see a CAPTCHA form (from Extension:ConfirmEdit)$wgGroupPermissions['EstablishedCitizen']['skipcaptcha'] = true;
# checkuser - Grants users with the appropriate permission the ability to check user's IP addresses and other information (from Extension:CheckUser)$wgGroupPermissions['ManagementCommittee']['checkuser'] = true;$wgGroupPermissions['Constable']['checkuser'] = true;$wgGroupPermissions['EditorialPersonnelAdministrator']['checkuser'] = true;$wgGroupPermissions['Founder']['checkuser'] = true;
# confirmaccount - Allows access to Special:ConfirmAccounts, which is the page that is used to confirm pending account requests at Citizendium. (from Extension:ConfirmAccount)$wgGroupPermissions['Constable']['confirmaccount'] = true;$wgGroupPermissions['EditorialPersonnelAdministrator']['confirmaccount'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['confirmaccount'] = true;$wgGroupPermissions['Founder']['confirmaccount'] = true;
# 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)$wgGroupPermissions['ManagementCommittee']['newslettermembers'] = true;$wgGroupPermissions['EditorialCouncil']['newslettermembers'] = true;$wgGroupPermissions['Founder']['newslettermembers'] = true;
# 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)$wgGroupPermissions['ManagementCommittee']['newslettermassmailer'] = true;$wgGroupPermissions['EditorialCouncil']['newslettermassmailer'] = true;$wgGroupPermissions['Founder']['newslettermassmailer'] = true;
# lookupcredentials - Allows access to Special:UserCredentials, which provides a users details that were provided upon registration (email address, biography, cv, etc.) (from Extension:ConfirmAccount)$wgGroupPermissions['ManagementCommittee']['lookupcredentials'] = true;$wgGroupPermissions['EditorialCouncil']['lookupcredentials'] = true;$wgGroupPermissions['Constable']['lookupcredentials'] = true;$wgGroupPermissions['Ombudsman']['lookupcredentials'] = true;$wgGroupPermissions['Founder']['lookupcredentials'] = true;
# renameuser - Gives the right to rename users (from Extension:Renameuser)$wgGroupPermissions['Constable']['renameuser'] = true;
# requestips - Adds IP address to the information on Special:UserCredentials (from Extension:ConfirmAccount)$wgGroupPermissions['ManagementCommittee']['requestips'] = true;$wgGroupPermissions['EditorialCouncil']['requestips'] = true;$wgGroupPermissions['Constable']['requestips'] = true;$wgGroupPermissions['Ombudsman']['requestips'] = true;$wgGroupPermissions['Founder']['requestips'] = true;
# editprotectedtemplates - allows editing of protected template$wgGroupPermissions['ManagementCommittee']['editprotectedtemplates'] = true;$wgGroupPermissions['EditorialCouncil']['editprotectedtemplates'] = true;$wgGroupPermissions['Constable']['editprotectedtemplates'] = true;$wgGroupPermissions['Ombudsman']['editprotectedtemplates'] = true;$wgGroupPermissions['SeniorTechnicalStaff']['editprotectedtemplates'] = true;$wgGroupPermissions['InterfaceDeveloper']['editprotectedtemplates'] = true;$wgGroupPermissions['Founder']['editprotectedtemplates'] = true;
Modifications to the Simple Machines Forum Configuration
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
- ↑ Wiki software - http://www.mediawiki.org
- ↑ Forum software - http://www.simplemachines.org/
- ↑ http://forum.citizendium.org/index.php/topic,3146.msg28897.html#msg28897
- ↑ http://forum.citizendium.org/index.php/topic,3193.0.html
- ↑ See: http://www.mail-archive.com/[email protected]/msg00307.html
- ↑ http://forum.citizendium.org/index.php/topic,3193.0.html
- ↑ http://www.mediawiki.org/wiki/Manual:User_rights#List_of_Permissions
- ↑ http://forum.citizendium.org/index.php/board,77.0.html
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)