Talk:Global sysops

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Opting wikis out of global sysops[edit]

What about moving wikis out of global sysops based on the policy and without local discussion? The wiki in question is de.wikivoyage with over 10 admins, a few bureaucrats, and several active recently - but I am sure there are others.

I've certainly done mass checks for opting them in - but not out. On one hand it enables global sysops to focus on the wikis that really need help, and provides less of an opportunity for a global sysop to cause issues. On the other, it decreases the ability of global sysops to respond in urgent cases. --Rschen7754 18:12, 17 January 2021 (UTC)

Ideally we should be opting them in and out as they meet the criteria unless the project explicitly discussed to be kept opted-in or opted-out. However as things stand now it is all a very manual and time consuming process. I wish we could have some web app or bot that we could check from time to time and do this more often. —MarcoAurelio (talk) 21:53, 19 January 2021 (UTC)
This should be pretty easy to do. How would you name such bot/tool? Platonides (talk) 22:09, 19 January 2021 (UTC)

Question Question: Why would we force any wiki out of global sysops? What are you trying to achieve. We thoughtfully, as global sysops, leave them alone based on local conditions, why force the removal of tools access. If it is just for a reporting sense, then that seems a different set of criteria and thinking. —The preceding unsigned comment was added by Billinghurst (talk) 23:02, 19 January 2021 (UTC)

Adding global lock/block[edit]

I was wondering on what the community thinks of it now. For reference, the 2010 (and 2008) proposals included them but was removed in the end due to opposition. I address each part below:

Global lock/block[edit]

One of GS' purposes is to handle vandalism on small wikis, and a "negative" aspect of SUL means that vandalism can easily spread everywhere (that is, users blocked on one account with no good purpose can easily do the same on other wikis, and the same can apply to IP addresses). While stewards are well equipped to handle global locks, they do have other things to bother with as well and I believe that GS can handle locking accounts that are used purely for vandalism (or even spam, though that does not appear to be explicitly mentioned as a GS role).

Considering that GS users have a 2-week discussion period to get elected, I would argue that they are sufficiently trusted. I should reiterate that GS would not be allowed to lock accounts other than what's explicitly allowed - stewards would still lock non-vandalism accounts as before.

Global rollback[edit]

[removed, thanks MF-Warburg for pointing out my error]

Note that I am not a GS or steward myself, and hence could have gotten some of my thoughts wrong - but feel free to correct me. Leaderboard (talk) 18:45, 19 January 2021 (UTC)

1st part see this, 2nd part, any global sysop can get global rollback if they ask for it, Global Rollback policy already have this in the fine print. Camouflaged Mirage (talk) 18:52, 19 January 2021 (UTC)
Thanks @Camouflaged Mirage:, I didn't spot that RfC, though feel that discussion on that has been quite low. Leaderboard (talk) 18:54, 19 January 2021 (UTC)
And GR isn't a subset of GS, as GR is applicable in all wikis, GS isn't. However, as if a candidate can pass GS, there isn't much reason why they cannot pass GR. Camouflaged Mirage (talk) 18:55, 19 January 2021 (UTC)
This was recently proposed in Requests for comment/Renew Global Sysops policy (something similar before in Wikimedia_Forum/Archives/2020-07#Proposed_new_user_group:_Global_blocker) and not accepted - see my comments there for my opinion.
I don't quite understand what you mean by the rollback part. Afaics, the Global Sysop group contains all the rights of the Global Rollback group already, except patrolmarks. --MF-W 18:54, 19 January 2021 (UTC)
@MF-Warburg: You're right - the existing documentation (and past discussion) made me think that wasn't the case. I'll remove that part. Leaderboard (talk) 18:56, 19 January 2021 (UTC)
The only difference as I pointed above is that GR is active in all wiki, GS is bound by wikiset 7. Camouflaged Mirage (talk) 18:58, 19 January 2021 (UTC)
You're right indeed, I have removed that part entirely as a result of my misunderstanding that MF-Warburg pointed out. I'm currently not focusing on the wikisets. Leaderboard (talk) 19:01, 19 January 2021 (UTC)
I mean we can do another RFC, I think this needs a RFC to implement. But since the previous ones have little consensus, I think any new ones will be the same. I had no personal opinion on this yet. Camouflaged Mirage (talk) 19:06, 19 January 2021 (UTC)

Comment Comment global (locks and blocks) bits are essentially the reason for being of stewards, and part of that role is not just the action of locking and blocking, and also the examination of the consequences of those actions. The consequences of those actions require access to private information, which requires identification to WMF.

If we don't have enough stewards, then get more stewards, not delegate role. It is not the role that has been allocated or the purpose of GS, we are just admins.  — billinghurst sDrewth 03:53, 20 January 2021 (UTC)

@Billinghurst: This isn't something I can fully agree with. The reason is that I am focusing specifically on locking accounts due to uncontroversial vandalism alone. Just like GS aren't supposed to use their, say rollback, rights for anything else, the same would apply for locking accounts. Stewards would still be expected to lock accounts of any other nature. I don't think "access to private information" is required for detecting clearcut spam, for instance. Leaderboard (talk) 09:06, 20 January 2021 (UTC)
@Leaderboard: This is my opinion as an existing global sysop and having been a steward. I see this as being half-pregnant. It is my opinion that the solution is not to disperse the right, but to have the right number of stewards available at the right times. That needs to be part of the consideration of election processes, and review processes; not stuck onto an existing right. If a global sysop wants to lock and global block then put your hand up to be a steward.  — billinghurst sDrewth 21:46, 21 January 2021 (UTC)
I think locking an account itself is trivial, and the difficult and time-consuming part is the followup loginwiki CU. If the underlying IP address remains unblocked (global locks are unlike local blocks that can enforce an autoblock), vandal / spambot accounts may continue to be created. Locking accounts without CU can actually be of little help. -- 94rain Talk 15:28, 20 January 2021 (UTC)
  • Stewards make CU on loginwiki and in this way they get healthier results for global lock/blocks. I don't think it would be beneficial to give this global lock and block rights to global sysops. --Uncitoyentalk 15:45, 20 January 2021 (UTC)

Noting discussion re "Add 'editcontentmodel' for GS"[edit]

Those interested the reach of global sysops may be interested to participate in the discussion Stewards' noticeboard#Add "editcontentmodel" for GS (vicinity of special:permalink/21175106).  — billinghurst sDrewth 11:33, 3 March 2021 (UTC)

Noting that this right change was undertaken.  — billinghurst sDrewth 00:10, 30 March 2021 (UTC)

Vandals in Malay Wiktionary[edit]

There is an IP address creates new pages in foreign language. Do delete the pages and block the IP address. We don't have any active admins for a long time. --Tofeiku (talk) 17:26, 29 March 2021 (UTC)

@Tofeiku: Pages deleted and IP address blocked. The better spot for reporting issues is SRM as this is more an explanatory page for the role, rather than a request to act page. Also to note that adding your local {{delete}} template will have it listed for action of stewards and global sysops, though ore reactively and less urgently than a request to SRM.  — billinghurst sDrewth 00:09, 30 March 2021 (UTC)