Talk:Global sysops

Active discussions


Adding eswiktionaryEdit

Eswiktionary appears to have been opted-out since the wiki set was created, and I can't find a record of how the initial wikis included were determined. By default, it would fall under the scope of global sysops since it has under 10 admins - can it be removed from the wiki set (i.e. added back to the wikis where GS can use the tools)? --DannyS712 (talk) 02:56, 29 October 2020 (UTC)

While that is part of the policy and I think it should happen - I've never found a steward brave enough to enforce it since the initial creation of the wikiset in 2010. (And for the record - that would include myself since I was a steward for a year). --Rschen7754 06:18, 29 October 2020 (UTC)
I think it has to be proposed locally first before we on Meta can do any change. Even if it had zero local admins, if community deny global sysops access, it can't be implemented.—Teles «Talk to me ˱C L @ S˲» 06:27, 29 October 2020 (UTC)
I'm not sure this is correct - if there's a discussion on file where they explicitly rejected it, that's one thing; but otherwise stewards have added/removed wikis under the 3 active admins rule with no problems. --Rschen7754 06:41, 29 October 2020 (UTC)
Sounds about right. By checking the logs, I can see that it was done mostly for clearcut cases, when there were a few months of inactivity and only one or two admins. It could be more precise.—Teles «Talk to me ˱C L @ S˲» 07:01, 29 October 2020 (UTC)
Just start a local discussion. If the wiki is indeed dead, no objections will occur... --MF-W 14:05, 29 October 2020 (UTC)
@MF-Warburg @Teles coming back to this (sorry, completely forgot) I couldn't find a version of either "Requests for administrator attention" (wikidata:Q3907246) or "Administrators' noticeboard" (wikidata:Q4580256) via local searches or on the wikidata items, so I don't know where to have a local discussion DannyS712 (talk) 00:32, 7 December 2020 (UTC)
@DannyS712: It shouldn't be restricted to admins. It has to be put on a highly visible discussion page, like a Village Pump or similar. I think this is the page to be used.—Teles «Talk ˱C L @ S˲» 00:59, 7 December 2020 (UTC)
(ec) eswiktionary doesn't have an administrators' noticeboard; such discussion should take place at Wikcionario:Café. Sgd. —Hasley 01:02, 7 December 2020 (UTC)
eswiktionary was initially opted out when the wikiset was created because at the time the wiki had enough administrators of their own. I am not aware of any local discussion explicitly opting out, or denying opting-in so if the wiki nows meets the GS#Scope criteria, just add it as its addition is based on the existing policy. Thanks. —MarcoAurelio (talk) 11:11, 7 December 2020 (UTC)
See also Global sysops/Local discussions for a list of wikis that, regardless whether they're in Scope, have decide to opt-in/opt-out and that should not be added or removed without their explicit consent first. —MarcoAurelio (talk) 11:14, 7 December 2020 (UTC)
  Added and notified about it; and also given instructions for explicit opt-in/opt-out if they want to make a choice. —MarcoAurelio (talk) 11:30, 7 December 2020 (UTC)

Opting wikis out of global sysopsEdit

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: 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/blockEdit

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/blockEdit

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 rollbackEdit

[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 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)
Return to "Global sysops" page.