Meta:Requests for comment/Allow global sysops on Meta

An editor has requested comments on the issue described below. Please feel free to share your thoughts.

Statement of the issue

As the title says. It is true that global sysops are mainly meant for smaller wikis, but that does not have to always be the case, and several larger wikis indeed allow global sysops (the 10 admins/3 active admins rule is more of a guideline). My proposal is to allow global sysops on Meta-Wiki. After all, a lot of the cross-wiki vandalism invariably comes on Meta, and I don't see the point of having such users apply for local Meta adminship as well.

The scope will remain the same (uncontroversial vandalism/spam removal) - Meta admins do the rest, just as before. In particular, they cannot assign or change any user rights. Leaderboard (talk) 07:21, 18 June 2025 (UTC)[reply]

Comments

Question: does your proposal include allowing GS to edit global abuse filters and the global SBL or do you think that’s outside the scope of "uncontroversial vandalism/spam removal"? --Johannnes89 (talk) 08:05, 18 June 2025 (UTC)[reply]
@Johannnes89 Personally I would include abuse filters and the SBL, but I'll leave it up for the community to decide in the end. Leaderboard (talk) 09:28, 18 June 2025 (UTC)[reply]
Oppose I don't think this is needed. Not only do we already have 79 local admins, but we also have plenty of active administrators. There are almost never backlogs at WM:RFH or Category:Deleteme (places where vandals/spammers are generally reported). — xaosflux ^Talk 15:12, 18 June 2025 (UTC)[reply]
Just because there are a lot of active administrators (half of whom wouldn't be one if GS could access Meta) does not invalidate my proposal. As a "host", Meta is unique. Leaderboard (talk) 18:34, 18 June 2025 (UTC)[reply]
Meta also has unique security risks with global userscripts; as GS's have intadmin access baked in I don't think that is something we should import here by default. — xaosflux ^Talk 18:37, 18 June 2025 (UTC)[reply]
Then this can be restricted (i.e, GS cannot use interface-admin rights here). Leaderboard (talk) 04:47, 19 June 2025 (UTC)[reply]
I don't think reducing that technical control to an administrative control is good practice. — xaosflux ^Talk 09:28, 19 June 2025 (UTC)[reply]
Oppose per Xaosflux. * Pppery * _{it has begun} 15:26, 18 June 2025 (UTC)[reply]
Oppose I simply do not see a need at this time. I also think the global sysop role is expanding, not to a stage where it's yet close to truly global, but we need to remember it's primarily about small wikis that need our help, and this is not one of those cases. --Ferien (talk) 06:35, 19 June 2025 (UTC)[reply]
Oppose per the comments above. Ternera (talk) 13:58, 19 June 2025 (UTC)[reply]
Strong support, quite coincidentally I was also thinking about this about a month ago. I'll list some of the points that stand out to me:
- Firstly, I'd start by re-stating that global sysop is one of the sensitive permissions out there (including within it sysop and interface editor permissions on most wikis, many of them even being wikis with an active community of their own) and anyone entrusted with GS has a high level of trust with them.
- Secondly, I do not think that any global sysop in good standing without any particular issues would have the slightest issue in obtaining Meta admin permissions too. For some of the very recent examples: A09 and Ternera.
- Next, most of the "uncontroversial anti-vandalism work" on Meta that would fall within the scope of global sysops, in my experience, is actually quite similar (near-identical if you ask me) to the uncontroversial anti-vandalism work on other similar multilingual wikis such as mediawikiwiki, outreach, etc. which are already in GS scope. Additionally, almost all global sysops do have anti-vandalism experience at Meta also.
- In my opinion, it is still fine if some technical control is reduced to a policy-based control for things like Meta IA, global abuse filters, spam blacklist, etc. (whatever decided by the community to be considered outside of GS scope) and I would trust global sysops to follow the policy and in my opinion there is no harm in elected global sysops having technical access to these areas. If someone is a GS and not trusted enough to be able to work with a policy-restricted but technical access to something then I'd rather reconsider the GS status of them.
- Finally, as for the benefit of this proposal, I have frequently seen global sysops having to request simple and uncontroversial admin actions like deletions and blocking that they could be able to do by themselves if this proposal goes through. So this would definitely increase efficiency in this aspect even if Meta doesn't strictly need more admins.
– Svārtava (t ɕ) 18:54, 19 June 2025 (UTC)[reply]
Neutral I am quite convinced that GS are trusted enough to delete spam and do countervandalism blocks if and when needed, almost everywhere. I am also convinced that someone else should be able to assist Stewards to globally "terminate" accounts that are in blatant violation of SPAM/vandalism policies and/or LTAs, since this is a real situation that sometimes happens and produces multiple requests and delay. Id est, if one is really concerned about users jumping from on project to another, adding a global block tool is far more effective than adding a single project to GS wiki set (even meta.wiki). --M/ (talk) 20:12, 19 June 2025 (UTC)[reply]
I agree with M7 above. I do think GS should have access to the global SBL to handle crosswiki spam, as well as some way to deal with project-hopping vandals, since it's not always easy to find an active steward. However, this proposal doesn't seem to do much to help their scope. I would support giving them access to global abuse filters and the global SBL through a local user group; possibly even global block access.--BRP^ever 22:01, 19 June 2025 (UTC)[reply]
Neutral My thoughts here are mostly in line with BR's and M7's above. //shb (t • c) 23:14, 19 June 2025 (UTC)[reply]
Strong oppose Per xaosflux's comment on intadmin. Global sysops have the edituserjs right, which on most wikis means they could only edit a user's JS page on that site. On meta, they would be able to edit a user's global JavaScript files, which take effect across every wiki. While I trust that the global sysops probably would not do anything malicious with that access, a global sysop's interface editing abilities are not exactly thoroughly reviewed in the same way as we would review a GIE candidate's. EggRoll97 (talk) 00:15, 20 June 2025 (UTC)[reply]
Oppose per Xaos, including SBL access. I would prefer to see a track record of someone reporting domains for SBL inclusion before supporting them full access. XXBlackburnXx (talk) 06:16, 22 June 2025 (UTC)[reply]
Meta admins and global sysops (on other wikis) aren't asked to show prior work on SBL when applying, so this doesn't make sense? Leaderboard (talk) 12:10, 22 June 2025 (UTC)[reply]
Neutral. I was definitely struggling to efficiently deal with crosswiki vandals before becoming a Meta admin (where I can take actions here as well if needed) and would support limiting GS' actions to both vandalistic blocks and SBL handling. However, this is hard to enforce, especially since Metawiki is a busy place with lots of different editorial profiles (local admins/GSs/non-admin folks/stewards) so a mixed-scope policy like some wikiprojects in the GS set have is not feasible for Metawiki. Furthermore, allowing GS users to perform normal Metawiki admin duties would implement unseen dangerous editorial practices: GS is big enough toolset to learn for efficient usage, we don't need even more to start with (especially on a wikiproject where a mistake could have global consequences, which brings potential problems for admin newbies who jump the gun too many times).--A09|(pogovor) 15:02, 22 June 2025 (UTC)[reply]
Weak oppose per xaosflux and the following thread. --TenWhile6 18:51, 22 June 2025 (UTC)[reply]
"we already have xxx (active) local admins" is not a good point - mediawikiwiki has even more sysops, active sysops. But the ability to edit js pages is potentially dangerous, considering many scripts on metawiki have global effects. I lean toward oppose, sorry. Stang 13:04, 24 June 2025 (UTC)[reply]
Oppose per xaosflux. AramilFeraxa (talk) 15:17, 24 June 2025 (UTC)[reply]
Oppose largely per A09 and Stang. Jianhui67^{talk★contribs} 08:52, 29 June 2025 (UTC)[reply]