Forum:Creating local CATS and GIM user groups

I want to explore the idea of creating local versions of CATS and GIM user groups for the English wiki.

Background

I discovered during Dianliang233's nomination for admin that the Chinese wiki has two user groups that we do not have on the English wiki. One is called Interface Administrator, which is essentially a local version of GIM, and the other is called Patroller (same name as ours, but different permissions) that is essentially a local version of CATS. Both rights can be granted by bureaucrats and don't have to be granted by Weird Gloop like CATS and GIM do. See zh:Special:UserGroupRights.

If you're not very familiar with CATS and GIM, CATS essentially have the portion of admin rights that are used in fighting vandalism, and GIM have the portion of admin rights needed to deal with technical aspects of the wiki such as CSS and JavaScript. Both positions are global, meaning that if a user has CATS or GIM user rights, they have those rights in every language wiki. Almost all other user rights are local, meaning that if you are granted user rights in one language wiki, they do not extend to any other language wiki.

During Mudscape's nomination for administrator, I realized that the "traditional" path to administrator is to go from having no admin rights to having full admin rights once you're considered trustworthy enough. All admins can block users, delete pages, and edit sitewide CSS and JS, even though not all admins use their full set of user rights regularly. Also during the nomination, some people at least implied that they think admins should be well rounded in both roles of an admin - fighting vandalism and having technical expertise. There might be a group of people who could reliably do one role or the other, even if the community isn't sure they're trustworthy enough to do both. Also, having "junior" admin roles could serve as a more natural progression to full admin.

Counterargument

A good counterargument is that these two groups are unnecessary. If you're considered trustworthy enough to delete pages and block users, then hopefully you can be trusted to not mess around with the site's CSS if you don't know what you're doing. Conversely, if you're trusted enough to constantly tinker with the wiki's code, hopefully you can be trusted not to indefinitely block someone for disruptive editing when a stern warning might suffice.

Note

I did consider waiting until after Mudscape's nomination had been resolved before posting this out of fear that the discussion would spill out over here. But I saw some hints about this topic in said nomination, and it occurred to me that if we already had these roles and it was normal to gradually step up admin rights, then that nomination would probably be for interface admin and be less chaotic.

Rampage455 (talk) 03:12, 11 March 2025 (UTC)

Making this comment to enable quickly replying using DiscussionTools. -~- Nerdyguy2000   Talk   Edits  03:25, 11 March 2025 (UTC)

I like this idea. But I'll take my "usual" approach to discussions and state my opinion, but not my stance. That is, not until enough discussion takes place. Like I said, I like this idea, and I think it might make nominations easier to decide on because it'll allow smaller "footsteps". -~- Nerdyguy2000   Talk   Edits  03:25, 11 March 2025 (UTC)

Okay, so there might not be any need for these groups. Does that mean it's not a good idea?

Sure, CSS and JS are powerful. But why does that mean people have to have vandal fighting tools beforehand?

I think these will help with granularity a bit in a sort, then people looking for interface admins won't ask vandal fighting ones. -~- Nerdyguy2000   Talk   Edits  14:30, 11 March 2025 (UTC)

I agree with Harri in that it'd make it complicated. But my second comment has some counter counter arguments. -~- Nerdyguy2000   Talk   Edits  18:34, 11 March 2025 (UTC)

👁 Image
 Support - I saw this coming or atleast something like this discussion taking place after Wilf's initial proposal in the wiki discord. I'm generally biased towards distribution of power and this does just that. Distribution of power (or, in this case, rights) leads to better management of the wiki in the long run. I do have doubts if it would be good to create a completely new role similar to CATS or to give blocking/deleting permission to patrollers or doing nothing for this right and letting the admins have it only. Interface administrator would be a good role if created. - 👁 Image
StizzurpXDD^(talk) 04:31, 11 March 2025 (UTC)

👁 Image
 Oppose — I see no need in intermediate user groups like these. — BabylonAS 05:32, 11 March 2025 (UTC)

In my opinion the only sensible change is adopting MediaWiki’s (relatively new) default practice of moving the highly sensitive interface rights from sysops to interface admins, which would thus be “above” sysops in a similar fashion to bureaucrats. This might in turn make the regular sysop group more accessible. — BabylonAS 18:43, 11 March 2025 (UTC)

👁 Image
 Oppose interface admin, 👁 Image
 neutral for ZH-based patroller, 👁 Image
 oppose literal local variants of CATS and GIM with same name. User groups are a delicate part of the wiki environment, and adding more groups adds a layer of unconscious user hierarchy and segregation.

-

An interface admin usergroup is not needed on this wiki right now because it exists on Wikipedia due to the amount of administrators they have, they had issues with letting admins be able to edit interface when they are a lot and many of them focus on editing content rather than design, which is an issue we do not have as of now, and if issues arise from misuse of tools, each admin can use the talk page of the other admin to tell them what they did wrong and best practices for future. Interface admins, at least on Wikipedia, are the same rank as regular admins, but they serve different purposes, while Chinese wiki is not like Wikipedia in this because their admins (sysops) also have the permissions to edit interface, unlike Wikipedia, which adds a hierarchy layer. I can't give more opinions about Chinese wiki because they have a different culture and vision of how to do stuff, so this is the most I can say with all I know.

-

On the other side, having a "middle point" between a patroller and an admin is something I actually quite like. Chinese wiki has patrollers, which is something I cannot say stuff about because I don't know how does the community there work, but I can talk about what we have on the Spanish wiki, which are content moderators (see our es:Special:UserGroupRights), an usergroup that could work if it's given only with a somewhat less strict guideline than adminship. We have this usergroup on the Spanish wiki to let editors who edit frequently the wiki use tools to make their maintenance labors easier. I do know this is an extra layer of hierarchy, and one that needs to be constantly watched to prevent someone from going rogue or something, though as of now we have not had this issue since we give this group unfrequently due to our low activity. But the main benefit of this usergroup is that if an admin is not present on the wiki, they are able to deal with common wiki issues. This usergroup exists also because admittedly our userbase lacks users with experience with CSS and JS, and letting an userbase like ours to edit JS or CSS and Lua modules has a big risk. English wiki does not have this issue, as they have admins from many timezones, as well as way more experience with dealing with these types of pages. I'm neutral because it's something that it's not needed technically, it's more of a junior admin or something, in which case giving admin could be better due to the larger activity this wiki has.

-

These are just my current point of view, it's not something set in stone anyway. --Supeika (talk) 06:38, 11 March 2025 (UTC)

👁 Image
 Oppose per Supeika. – 👁 Image
Delycache ^{(Talk | Contributions)} 08:05, 11 March 2025 (UTC)

As a patroller for Chinese Wiki for 16 months, I can share some information about these user group with you. There are a lot of differences between Chinese and English in terms of user groups.

First, the duration. The duration of patrollers, administrators, interface administrators and even autopatrolled users are not infinite. Patrollers, administrators and interface administrators need to conclude what they did in the last term and renew their rights on admin notice board. Bureaucrats will decide whether or not to renew the rights based on their activity in the last term. This ensures that users with important rights are active, especially patrollers and administrators. Patrollers may also nominate new autopatrolled users within the administration group at the end of each month based on edit quality and other stuff, but the final decision are made by administrators. I think this motivates editing and reduces the burden of patrolling.

Second, the responsibility culture, similar to the accountability culture in the society. Although patrollers on Chinese Wiki have more user rights, including block others from editing, search-digest block, big delete, undelete, view detailed private abuse log, semi-protect a page and mark bot edits other than patrol and rollback, the corresponding responsibility should not be neglected. Patrollers have five main responsibilities, including staying active, patrolling in time, rollbacking in time, updating important pages and executing consensus from community. Administrators also have responsibilities, though user rights are the same with English. The responsibility culture is part of modern Chinese culture. English Wiki does not have these responsibilities I think.

Third, different conception and requirements of patrol. There are two major differences. One, every revision needs to be patrolled. Two, patrollers have to verify whether information in every revision is true as well as check whether the revision meets style guide, notability and other policies or guidelines. The reason is that the editor community and readers have higher expectations on us due to Chinese culture. As the second largest language wiki in terms of page of views and number of edits per day, Chinese Wiki has a lot of edits to be patrolled, which is quite challenging for patrollers, especially in holidays. Maybe you think this is like censorship, which is a negative word. However, no vandalism are neglected. Most errors are corrected. Most pages follow style guide. These sacrifices may worth them.

Fourth, the demand of interface administrators. As you may know, Chinese Wiki actually contains three languages, i.e. simplified Chinese used in mainland China, traditional Chinese used in Taiwan, China, and traditional Chinese used in Hong Kong and Macao Special Administrative Region in China. The initial propose of setting interface administrators are quite simple: they are responsible for the conversion of different Chinese variants in MediaWiki namespace and in principle they should not have extra permissions with interface administrators other than handling Chinese variants. (I wonder why there's no English conversion among US, British, Australia, Canadian, New Zealand etc.) Interface administrators group can also give to trusted users who are experienced in CSS and JS, but actually this group is not open for requesting, yet from bureaucrats' invitation. Currently, there are three interface administrators, two of whom are inactive and do Chinese conversion only. The third user, zh:User:Leo768, is an active interface administrator as well as a patroller, who does all type of things.

I do admit there's drawback of policies on Chinese Wiki, such as higher demand for patrollers and administrators, a lot more difficult to edit articles because editors have to follow style guide relatively strictly, but, these policies better fit us. So much for the Chinese Wiki and now my opinion of implementing local rights is 👁 Image
 conditional weak support. English Wiki is far more international than Chinese Wiki, so we have to accept different cultures. It is extremely difficult that most editors can accept the changes if we just copy Chinese Wiki, and I'll 👁 Image
 Oppose. We may set up some groups which don't contain so many rights so as to divide the labor, but it needs further discussion because it's my incomplete idea.

I have been a patroller on English Minecraft Wiki as well for half a year, with over 4500 edits and 3000 patrols so far, and I don't see other patrollers are as active as me in terms of patrolling and rollbacking. I have been trying my best understanding, respecting and comparing English culture. I hope the information would be helpful for reference. 👁 Image
Wilf233_zhMCW（论·功） 10:15, 11 March 2025 (UTC)

👁 Image
 Support for a junior admin role, either expanding the rights of patrollers or setting up an entirely new user group. The ability to block, delete and protect is useful in fighting vandalism and I've always thought that it would be valuable for some non-admins to hold these permissions. A clear path of progression would hopefully attract more admins.

👁 Image
 Strong oppose for a dedicated interface admin role. It must be pointed out that the trust level for interface admins should be as high as regular admin, which makes this group pointless. A rogue interface admin can cause the same amount of damage as regular admins due to JavaScript. This is why WMF separated admin rights and interface admin rights on their sites, as most admins doesn't need these permissions. Interface admin shouldn't be considered a junior role. GIM Dianliang233 (talk) 11:07, 11 March 2025 (UTC)

It must be pointed out that the trust level for interface admins should be as high as regular admin, which makes this group pointless. - then we need to take away rights to edit site's CSS and JS from sysop group. At least that's how it works on English Wikipedia. Arina (she/her) 11:46, 11 March 2025 (UTC)

Sure then, I don't have a very strong opinion on this. I just wanted to say that it doesn't make sense to give non-admins interface admin. GIM Dianliang233 (talk) 12:07, 11 March 2025 (UTC)

What are you talking about? If non-admins having interface admin permission does not make sense, then why does every Wiki.gg wiki have Interface Administrator role? Use some common sense and first check before calling out anything as not making sense. 👁 Image
CaishenZhēn233 (talk) 12:15, 11 March 2025 (UTC)

Thank you for bringing this to attention. I just quickly checked Terraria Wiki whose size is comparable to this wiki, and it seems like every interface admin is also an admin there. Even if some wikis give interface admin to non-admins, this does not invalidate my points at all. GIM Dianliang233 (talk) 12:25, 11 March 2025 (UTC)

On wiki.gg the interface-admin group is mainly used for trusted wiki.gg community members from outside the local community to temporarily fix or improve the wiki skin, more similar to our GIM. In any case, we shouldn't just blindly follow the bad example of other wikis. -- 👁 Image
MarkusRost (talk) 12:37, 11 March 2025 (UTC)

The Aether Wiki on wiki.gg doesn't give regular admins some of the interface-related rights. ― BabylonAS 13:35, 11 March 2025 (UTC)

Support local CATS and interface manager groups. I don't like it when admins have almost infinite power they don't use. Arina (she/her) 11:45, 11 March 2025 (UTC)

👁 Image
 Neutral on a local anti-vandalism group. I don't really consider such a group necessary as most vandalism can just be undone by any other editor without special permissions. Also the scope for such a group would need to be defined properly to differentiate them from normal admins.

👁 Image
 Support creating a local interface admin group only under the condition to remove the relevant permissions from normal admins. The interface admin group members would then consist of a subset of the normal admins, restricting it to admins who are actually familiar with CSS and JS (like on Wikipedia).

👁 Image
 Strong oppose giving interface admin to non-admin users. Editing CSS and JS are the most powerful permissions we have on the wiki and the only ones that can create irreversible damage when abused. Anyone who can't be trusted with normal admin tools like block or delete, can't be trusted with editing CSS and JS either. -- 👁 Image
MarkusRost (talk) 11:52, 11 March 2025 (UTC)

👁 Image
 Strong support for adding new roles for interface and spam fighting. 👁 Image
CaishenZhēn233 (talk) 12:02, 11 March 2025 (UTC)

👁 Image
 Strong oppose. This is needless separation and complication for everyone from my view. If you can be trusted to edit CSS and JS, you can be trusted with vandal fighting tools. Nothing about Mudscape’s nomination indicated he would be incapable of using them, and this proposal is in response to his nomination. You should not need to use every aspect of your admin rights just to be one, it is fine to focus on one aspect, the ideal outcome here is for people to realise that fact, not have a total rework of rights.

If we split admin into local CATS and GIM, I can only assume I would only be given CATS. Even if this is not true, if my admin nomination happened in a world where this proposal goes through, I would only have local CATS. Sounds like it makes sense, I don’t even know CSS or JS. But despite me primarily focusing vandal-fighting, sometimes I implement a CSS fix on behalf of another user, or I can make minor tweaks like the brown movie infoboxes that I wouldn’t have done if not for my access to the rights (in truth, Violine implemented brown movie infoboxes, but it was my intention to do it myself, and I was only motivated to propose it because I had the rights to do it). I do not know CSS or JS, and yet I feel my access to the rights to edit them has been beneficial. I hope my point is understandable. I think things would be much messier if we split everything up, I’ve only ever been given a poor impression of Chinese Wiki’s administration system and that system inspires this proposal as well. Also, this proposal giving next to no argument for why it should be implemented doesn’t inspire confidence. - Harristic / Talk 👁 Image
12:26, 11 March 2025 (UTC)

If you can be trusted to edit CSS and JS, you can be trusted with vandal fighting tools - why? Arina (she/her) 12:41, 11 March 2025 (UTC)

Because JS and CSS editing rights lets you do whatever you want with the wiki. You need to be trusted to not do such drastic things without community discussion. You must be a competent, trusted, and experienced user to get CSS and JS editing rights. You can only be an actively bad administrator (deleting fine pages with no discussion, blocking people for personal reasons, etc etc.) if you are not those three things. - Harristic / Talk 👁 Image
12:48, 11 March 2025 (UTC)

You need to be trusted to not do such drastic things without community discussion. - a person knows CSS well enough to be an interface manager. How does that mean they know what vandalism is and how to fight it? You must be a competent, trusted, and experienced user to get CSS and JS editing rights. - yes, but these rights aren't about fighting vandalism. Arina (she/her) 12:56, 11 March 2025 (UTC)

You learn that as you edit a wiki, as you watch vandalism happen and blocks happen. You do not need extensive training or something, you just pick it up as you go along. As I said before, if you are getting CSS and JS editing rights, you’re a competent trusted experienced user, you will know what vandalism is and how to deal with it, because you’ve been on the wiki for well over a year. You may not be as good as a user who specialises in it, but you don’t need to be. - Harristic / Talk 👁 Image
13:03, 11 March 2025 (UTC)

Being a competent and trusted user includes knowing when not to use tools you don't fully understand. So even if an interface-admin really wouldn't know how to fight vandalism, they would have to be competent enough to be aware of their lack of knowledge and as such not use the tools in questions. This is the same as Harristic mentioned in his comment regarding his usage of CSS and JS editing access. -- 👁 Image
MarkusRost (talk) 13:24, 11 March 2025 (UTC)

I thought my original post was already too long, so I didn't put all of my thoughts in there. I actually didn't post this with the intention of saying that we necessarily should implement this particular change; having separate admin roles just seemed like an interesting idea worthy of community discussion. And while the Mudscape nomination pushed it along, the idea of making this forum topic has been percolating in the back of my mind since Dianliang233's nomination. If you'd like more reasons for why making some kind of change to admin rights might be a good idea, one is that every time someone is nominated for admin, they will always have to defend why they should be given access to all admin user rights even if they don't have much experience in either content moderation or css/js, or only plan on focusing on one area. Another is the principal of least privilege from information security, which is basically a best practices guideline that says users should be given the least amount of permissions required to do their job. I also definitely did not intend to propose or suggest that any current admin's user rights should change; if there were a change I thought of it as more of a moving forward type of thing. And I think a few other interesting ideas came out of this discussion such as periodic reviews/renewals for admins on the Chinese wiki, the Spanish wiki having a content moderator position that can delete pages and edit protected pages, but not block users. I'm not saying we should implement those on the English wiki, but if we ever decide that we want to retool user rights, other people have already come up different ways to do things. Rampage455 (talk) 11:48, 13 March 2025 (UTC)

> Another is the principal of least privilege from information security, which is basically a best practices guideline that says users should be given the least amount of permissions required to do their job.

This argument probably only applies to (regular admins don't have interface rights and they have to obtain interface admin) but not (give users only interface admins before they've become admin) because rogue interface admins can essentially perform any admin action through executing JavaScript on any admin/staff account once they visit the wiki. GIM Dianliang233 (talk) 11:56, 13 March 2025 (UTC)

👁 Image
 Oppose - The counterarguments are given in the original post. Mudscape 👁 Image
talk 17:26, 11 March 2025 (UTC)

👁 Image
 Oppose; There is no need for this particular right, especially for Minecraft Wiki. I saw some editors giving arguments regarding Wiki.gg roles. I'm from the Terraria wiki and can tell that interface admin role is given only to past admins and not to any editor through a consensus. I 👁 Image
 Support adding the ability for patrollers to block users and delete pages. I also suggest revoking the patroller rights of inactive users (If they have not shown a good use of their rights) if they are getting the ability to do so. DoctorePothole (talk) 05:43, 12 March 2025 (UTC)

Why do we need to turn patrollers into moderators? - Harristic / Talk 👁 Image
05:55, 12 March 2025 (UTC)

Okay, so there might not be any need for these groups. Does that mean it's not a good idea?

Sure, CSS and JS are powerful. But why does that mean people have to have vandal fighting tools beforehand?

I think these will help with granularity a bit in a sort, then people looking for interface admins won't ask vandal fighting ones.

Sure, it'll make things complicated. But it'll also make things easier. Which one is more important?

My stance is 👁 Image
 Weak support, but open to discussion. -~- Nerdyguy2000   Talk   Edits  14:53, 13 March 2025 (UTC)

👁 Image
 Important: I've opened a forum post on the Meta Wiki on implementing a local interface administrator group while removing the relevant sensitive rights from regular sysops: meta:Forum:Local interface administrators. — BabylonAS 12:28, 17 March 2025 (UTC)

Preface
I am creating a parallel proposal to the one made by BabylonAS on the meta forum; this version only applies to the English wiki. If you haven't yet read the Creation of separate user group for editing sitewide CSS/JS article on the MediaWiki meta wiki linked by Dianliang233 above and BabylonAS on the meta forum, I highly recommend it. It gives a good overview of why users need to have a very high level of trust in order to have rights to edit CSS and JS, and how that power could be used maliciously. Based on feedback and ideas from the comments, I was probably going to propose something like this eventually, but thought to do it now in case some people want to implement this on the English wiki, but not necessarily across all language wikis as proposed by BabylonAS on our meta wiki forum.

Proposal
The proposal is to create an interface administrator user group that has rights to edit CSS and JS, and to remove those permissions from the current administrator (sysop) user group. The proposed rights for these user groups would be mostly the same as interface administrators and administrators that MediaWiki uses. If a user has interface administrator rights, then they would almost always also have administrator rights.

Why create a new interface admin position?
As the wiki grows over time, the number of administrators may increase. While new administrators may be generally trusted community members, the amount of power and potential for abuse with regards to being able to edit CSS/JS is rather high. One user behaving maliciously or carelessly could cause significant disruption or damage (see article linked above). Even if we haven't needed it so far, it may still be a good practice to not automatically give all admins rights to edit CSS/JS and to more thoroughly examine users requesting those specific rights.

Would adopting this proposal result in any immediate changes?
Not necessarily. We could choose for all current administrators to be grandfathered in and given interface admin rights; this would maintain all the rights they currently have. Presumably, future administrators would not automatically be given interface admin rights and would have to justify their need to be given those rights.

What happened to the "local CATS" and "local GIM" from the discussion above?
Those were suggested as possible new user groups that would have been considered "junior" admin roles; however, with the amount of power each group would have, neither is particularly "junior". Under this proposal, the new version of the administrator group would be equivalent to "local CATS". And technically, the new interface admin user group by itself would be the equivalent of "local GIM"; however, due to the amount of power such a user group would have, it could never be considered a junior admin position, and that user group would usually also have administrator rights as is common practice on MediaWiki/Wikipedia.

Rampage455 (talk) 10:54, 19 March 2025 (UTC)

👁 Image
 Neutral – While interface editing is a sensitive right, I don't think MCW need to adopt WMF's approach due to our relative small scale. As many have said, adminship is a multifaceted position and I fear that this restriction might deter technical contributions by current admins are not familiar with technical issues yet. I also worry about potential bikeshedding over whether future admins should also hold interface admin rights. However the security argument does carry a lot of weight, so I cannot decide where I stand on this. GIM Dianliang233 (talk) 11:42, 19 March 2025 (UTC)

👁 Image
 Weak oppose, would make it a little complex. Besides this would probably do little to help the current RfA. Alternative idea: what if we just moved the JS and CSS rights to bureacrat? -~- Nerdyguy2000   Talk   Edits  14:12, 19 March 2025 (UTC)

👁 Image
 Strong Support for adding new roles for interface. 👁 Image
CaishenZhēn233 (talk) 06:19, 20 March 2025 (UTC)

I personally think this is only necessary if we plan to add a lot more admins in general, with the current amount of admins it would just make the permission setup here more complicated than it already is. I personally don't think we should do that but if we want to give away admin rights more frequently, it would make sense to add a local interface admin group as subset of admins. | violine1101 ^(talk) 23:54, 20 March 2025 (UTC)