Requests for comment/Renew Global Sysops policy

The following request for comments is closed. No consensus to implement any action. --Martin Urbanec (talk) 00:42, 23 October 2020 (UTC)[reply]

The global sysop policy was introduced in 2010 and has not changed. But a lot has changed in the projects and in the work.

For example, there are projects that used to have an active community and no longer exist today. Vandalism has changed too, with a lot more crosswiki trolls, spambots and harassment. That's why I have 2 proposals.

Proposal 1 Scope change:

See the current text at Global_sysops#Scope

By default, Global sysops are allowed to use their rights in wikis that have decided to accept global sysops.

When using the rights, global sysops should only use their rights as assistance. Tests, simple vandalism or the like should be left to the local administrators. Global sysops act at their own discretion in the event of cross-project vandalism, spam or harassment.

Projects may opt-in or opt-out at their own discretion if they obtain local consensus. Simply inform any steward of the community's decision. A wiki set is used to specify a list of wikis where global sysops do not have access Should the community can no longer manage its project standalone after a time, can a Steward revoke this decision after a previous discussion in Metawiki to protect the project. The local community needs to be informed at the start of the discussion. --𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 15:37, 4 September 2020 (UTC)[reply]

Proposal 2 add global block (IP):

Global Sysops may also assign global blocks according to the policy. — The preceding unsigned comment was added by WikiBayer (talk)

Discussion

Proposal 1

New Scope policy.

Oppose Keep the current opt-in by default. The phrase Global sysops are allowed to use their rights in wikis that have decided to accept global sysops sounds like an opt-out by default. If so, what if a wiki that once had no community now has a community? Too much opting-outness! Can I Log In (talk) 22:37, 15 September 2020 (UTC)[reply]
Oppose Re: "Tests, simple vandalism or the like should be left to the local administrators. Global sysops act at their own discretion in the event of cross-project vandalism, spam or harassment." This is unnecessarily restrictive. IMO, global sysops should be able to clear up simple (one-wiki) vandalism on wikis with no admins, or when no local admins are around to deal with it. This gets the problems fixed sooner and reduces the burden placed on small wiki admins. If you were to replace this with language about not acting on wikis with active admins (e.g. as defined by Hoo man's script), then that would be better, but I still don't see how making the policy any more restrictive would actually help; it seems fine as is. Uncontroversial maintenance or assistance other than anti-vandalism/spam/harassment work should also be explicitly permitted. All in all, I don't see any benefit to limiting the scope of actions to dealing with cross-project abuse, which is what you're essentially proposing as far as I can tell. PiRSquared17 (talk) 22:48, 15 September 2020 (UTC)[reply]
Oppose The current policy works very well and I see no need to change it. This proposal does not seem very well-thought-out. As User:Can I Log In points out, it would be more restrictive than the current one by requiring every wiki to explicitly opt-in. Meanwhile it would also add a condescending process to force-opt-in projects by a Meta discussion, as opposed to a local discussion. I strongly oppose both ideas. Additionally, I agree with PiRSquared's analysis. --MF-W 00:02, 16 September 2020 (UTC)[reply]
Oppose There is room for improvement in the status quo (I think the defaults of 10/3 need to be strictly enforced) but this proposal is not it. --Rs chen 7754 06:02, 16 September 2020 (UTC)[reply]
Oppose unnecessarily limited. —Atcovi (Talk - Contribs) 14:53, 22 October 2020 (UTC)[reply]

Proposal 2

Add global block.

Strong oppose Global sysops are sysops on wikis that are opted-in. They are not stewards. I'd only support if global account management is included, but that brings more problems. Can I Log In (talk) 22:30, 15 September 2020 (UTC)[reply]
Note: This was the most controversial part of the 2010 GS proposal, and was removed as a compromise per Global sysops/Vote. There have also been other discussions about granting global sysops these rights, or creating a new global blocker group. Most recently: Wikimedia_Forum#Proposed_new_user_group:_Global_blocker. PiRSquared17 (talk) 23:27, 15 September 2020 (UTC)[reply]
Oppose As a global sysop, I should have rights on wikis that are opted-in, not everywhere. --MF-W 00:18, 16 September 2020 (UTC)[reply]
Oppose Global blocks affect wikis that may not like the presence of global sysops in their communities, so this is a definite no from me. —Atcovi (Talk - Contribs) 14:52, 22 October 2020 (UTC)[reply]

General discussion

The only reason brought forward by the proposer of this RFC which addresses several different things (not just 2 things, see details at the comments for proposal 1) is that "a lot has changed in the projects and in the work" since 2010. That goes without saying, really. It can't be the justification of such an RFC. Please please add a more detailed explanation of why you propose these changes. You say For example, there are projects that used to have an active community and no longer exist today. I guess that you want to address this part by the forced opt-in you propose, but wouldn't it be a much better solution to simply identify wikis where GSes should have access, according to you, but currently don't, and locally propose their opt-in to the GS wikiset? Incubator, which is by no means an inactive wiki, was recently opted-in to Global Sysops on the proposal of a steward. — Then you say Vandalism has changed too, with a lot more crosswiki trolls, spambots and harassment. Is that the reason for why you propose GSes should be able to issue global blocks? I doubt it's even true, lots of trolls, spambots and harassment are with us since at least 2007, when I started becoming active here, so fundamentally nothing changed since the 2010 decision to not give global sysops these rights. Of course the question can be discussed, but, as PiRSquared17 points out, it has been done only recently. --MF-W 00:13, 16 September 2020 (UTC)[reply]
I am of the opinion that there is significantly more cross-wiki vandalism than before. Archives also show an increase in crosswiki vandals. Example:2020 Steward_requests/Global/2012-09--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 11:24, 16 September 2020 (UTC)[reply]

I agree with what was said above. I see the proposal more as a solution in search of a problem. Tell me the actual problem(s), how the current system fails to address it, and a solution and the strengths and weaknesses proposal. At the moment the only particular issue that I see that needs addressing is that one active communities with local rights only become moribund, and there is no ready ability to clean up that wiki. To me it aligns with the changes that we made with AAR that we need an ability and criteria to return those wikis to being global sysop communities. Create some minimum criteria that need to be met and and maintained, eg. a wiki needs to maintain XX many active administrators each year and that would be looked at four time points through a years. Maybe make it two factor, and add counts of inactive requests for a period of time. — billinghurst sDrewth 11:23, 16 September 2020 (UTC)[reply]
The problem is that blocking locally doesn't stop the trolls. For example. A troll is active in the bat-smgwiki, after blocking it switches to astWiki, after blocking it switches to the next wiki and .... Global syspos also no have powers in opt-outed Projects because of this right, since global blocks may only be assigned if it is a matter of "widespread cross-wiki vandalism" (see policy for global block).
Not sure I fully agree with your synopsis. I would say that the steward group has this role to manage xwiki trolls, how is that not working? If you want that ability, apply for the role. It is not the role of a global sysop to resolve the issue of opted-out wikis, it is there issue. Don't try and own the problem. — billinghurst sDrewth 11:26, 16 September 2020 (UTC)[reply]

PiRSquared17 In the discussion it was about creating a new group. This was rejected, but there were several who said that it makes sense to give GS the global IP block right.

To 1.:There have been problems, for example amWiki was flooded with spam for a long time and it took a long time for a local user to approve the application to allow opt-in--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 11:13, 16 September 2020 (UTC)[reply]
- Primarily, that's that one user's problem, as one assumes he wants to use the wiki. --MF-W 14:45, 16 September 2020 (UTC)[reply]