Stewards' noticeboard/Archives/2021-09

Inactive admins on nl.wikivoyage

There are several inactive (one approaching 10 years) admins on nlwikivoyage: [1]

They have not been removed because we believed that nlwikivoyage has an activity policy (2 years, email required): [2]

However, subsequent discussions with the remaining active admins make me think that it was just copied from the English Wikitravel and was never a formal policy [3][4]. It was also summarily changed in 2013 [5] with no apparent discussion behind it.

Therefore - I think that this is not really a policy and that AAR should apply. As an alternative, someone could email the inactive admins and then fulfill the local policy. But I don't think we should have inactive admins and no way to remove them. Thoughts? --Rschen7754 04:04, 19 September 2021 (UTC)

The purpose of the policy was to put an end to moribund management. It doesn't sound as if the policy is operational, so moribund ignored policies are not really policies and unless they can demonstrate active compliance to their policy, I think it should be seen as in obeisance until they can demonstrate otherwise.  — billinghurst sDrewth 07:39, 19 September 2021 (UTC)

Are there any objections from current stewards before I make the changes on User:Openbk/list2? --Rschen7754 06:10, 26 September 2021 (UTC)

@Rschen7754: Checking the above discussions, I think we should add it, yes. I think the 2013 change is no coincidence either as AAR was first run in 2013, so I'm asuming they were trying to describe what'd happen to inactive admins based on the global policy. Two admins/crats stated that they are not aware of any local policy as per the diffs above, so I think we should trust their knowledge of local affairs and run AAR accordingly when the time comes. Thanks. —MarcoAurelio (talk) 15:18, 29 September 2021 (UTC)

Thanks, I've changed that and commented out the section on Admin_activity_review/Local_inactivity_policies. --Rschen7754 18:06, 29 September 2021 (UTC)

This section was archived on a request by: Martin Urbanec (talk) 22:19, 2 October 2021 (UTC)

2022 elections/confirmations

Maybe this is not the right place to ask about it, but are there any plans to make the statements and Q&A sections translatable using mw:Extension:Translate for the coming election? - Xbspiro (talk) 16:29, 28 September 2021 (UTC)

I am not sure there are plans, but it can be done, yes. --Base (talk) 00:23, 29 September 2021 (UTC)

@Xbspiro: Translation only really work well on mostly static pages, less so for dynamic text, ie. question pages. I would suggest that the self-nominating statements are the only component that could readily fit into the translation: ns. Have a look at the election system pages for 2021 Special:PrefixIndex/Stewards/Elections 2021/  — billinghurst sDrewth 12:32, 29 September 2021 (UTC)

Actually, I have translated some statements earlier, but the drop-down menu used on the statements pages for language selection stopped working for me sometime last year(?) - hence my question. And it would be nice to get notifications when the original page gets updated. My guess is that even though statement translations are encouraged, they are largely overlooked by the translator community as statements do not get marked for translation via the extension. Regarding the question pages, I see where you are coming from, and I sincerely doubt that we would get many translations of those. Nevertheless I would still see them valuable, especially in contrast with the statements. - Xbspiro (talk) 22:13, 29 September 2021 (UTC)

Great feedback, and thanks for raising the issue. Aaaaaand looking at Template:Sr-elections 2021, you'd have to say that it would greatly simplify things. I'd say that we just need to get someone to setup Template:Sr-elections 2022 ahead of time so that the stewards are faced with a piece of easiness. Always a case making things easy, or we fall back to what worked last time.  — billinghurst sDrewth 22:25, 29 September 2021 (UTC)

Oh and you said confirmations in your subject, so that is special:PrefixIndex/Stewards/Confirm/2021 and someone working on a success/derivative to Template:Steward confirmations statement. Template:Snippets/personal information] needs doing, and that looks like a good one to convert right now and have general usage. I might poke Meta:Babel to see if there are any takers.  — billinghurst sDrewth 22:36, 29 September 2021 (UTC)

What is "lock evasion"?

Lock evasion is a redlink but it's used as a rationale for locks occasionally. At Global locks it says that evasion of a global ban is reason for a lock, but not 'evading' a "global lock". A specific context is Steward_requests/Global/2021-05#Global_lock_for_Kashmorwiki where I asked this question before AmandaNP locked the account and neither the blocking admin or locking steward answered the question. That editor wasn't being disruptive at all, so the and are actively vandalizing now or obviously are otherwise being disruptive on multiple wikis are candidates for a global lock criteria was obviously not met. I saw some more "lock evasion" locks (by Amanda, but I'm guessing other stewards do these too) on my watchlist so posing the question now. ProcrastinatingReader (talk) 09:34, 30 September 2021 (UTC)

ProcrastinatingReader really? Lock evasion is synonymous to block evasion. Does everything need to be minutely defined? If someone has their account locked, you think that we should gives them a free pass to continue editing with a sockpuppet? That is naive. It is up to the steward's judgment to what they do with the sockpuppet accounts and that seems reasonable.  — billinghurst sDrewth 11:22, 30 September 2021 (UTC)

I will also note that the section you are referencing is the "making requests" section, and is not meant to limit a steward's action. That section would not necessarily mention user unidentified lock evasion, as that is typically only evident from checkuser data.  — billinghurst sDrewth 12:24, 30 September 2021 (UTC)

Completely serious, yeah. The guidance talks about global ban evasion, it seems like it would talk about lock evasion if it meant to talk about lock evasion. Then you get circular issues, as in that case, where local projects won’t consider an unblock due to ‘lock evasion’ and stewards won’t unlock because a local project hasn’t unblocked the editor. ProcrastinatingReader (talk) 15:04, 1 October 2021 (UTC)

You're missing the point. That list is guidance for when someone can request a lock. That's it. It is not there to give guidance to stewards.

Stewards are locking vandals, and problematic editors, and doing it upon request or through some of their CU checks of problematic xwiki accounts. If they are finding sockpuppets, they are sockpuppets, and they are making the assessment of what to do. At a local wiki there should be no need to block a locked account, and if it is blocked first then so be it. Stewards would not typically be pursuing a user only at one wiki. The cases like you mention are very rare, and those users can email stewards.  — billinghurst sDrewth 16:26, 1 October 2021 (UTC)

If I remember correctly, the editor in question said they emailed stewards multiple times and didn’t get an answer. It’s quite literally limbo. ProcrastinatingReader (talk) 22:29, 1 October 2021 (UTC)

If you have concerns about how stewards are managing their mail queue, probably better that as a straight request and conversation, rather than a surrogate argument. Stewards should answer reasonable questions about their processes, and should be able to summarily tell the community about the state of their mail queue.  — billinghurst sDrewth 23:40, 1 October 2021 (UTC)

My own straight request here was to see how these locks work, since (as I said before) it seems like these just put editors into limbo. I posed a specific question before (which I thought was quite reasonable) at the link I gave but Amanda silently locked without answering it. So I'd like an answer to that, ideally by a steward. ProcrastinatingReader (talk) 14:27, 2 October 2021 (UTC)

Hello @ProcrastinatingReader, a steward speaking. Thanks for your question – I'm trying to answer it below. Please note I'm not @AmandaNP, and I can't speak on her behalf – everything I say here is my own interpretation of the facts.

As far as I can see, the reason for the Kashmorwiki lock is simple: the CU block by @Mz7 shows English Wikipedia (as a project) considers the reincarnation as a disruptive one. Since the user previously contributed as Shahoodu, which is also locked (by myself), and is not active elsewhere, it's enough to justify a lock (in addition to that, [6] is also an interesting summary of the user's history).

For an appeal, personally, I do unlock accounts when a local appeals procedure was successful (especially on big established wikis, like English Wikipedia); [7] is an example of a previous case of a CU block+lock. I generally refer users to pursue local appeal first if possible -- that's because locals usually know the appellant better than the locking steward.

I think English Wikipedia should feel free to resolve the appeal as it wishes to -- if the block is removed, the account will very likely be unlocked (unless @AmandaNP knows something that I was unable to find even after thorough review). If on-wiki access is required for the appeal procedure (ie. if off-wiki process, like UTRS and/or AC, is not acceptable for some reason), I can imagine unlocking the account temporarily solely for the purposes of the appeal.

For the email queue, unfortunately, it's currently filled with a lot of mails (nearly a thousand of them) . We're aware of the problem, unfortunately, it takes some time to process them all, and we're all hard-working volunteers . I'll find an email from Kashmorwiki and reply to them later today.

I hope this all makes sense. Let me know if you have any other questions. Best, Martin Urbanec (talk) 22:18, 2 October 2021 (UTC)

Probably worth considering less hard blocking so many ranges and doing so so often with the only means of contact being email. That you have 1000 email sounds like you have an upstream problem that needs addressing.  — billinghurst sDrewth 06:37, 4 October 2021 (UTC)

@Billinghurst We're aware of that issue, and discussing potential solutions internally (one of the options is using a better-scaling unblock system), but so far, no decision has been made. Martin Urbanec (talk) 08:41, 4 October 2021 (UTC)

¯\_(ツ)_/¯ I am reflecting, not criticising. I am just reporting what I am seeing when attending to local block requests that are global requests, and the number of hard hard hard blocks that I am seeing, and comparing it to my time with that button. There are positive and negative consequences for actions and inactions. I would say that while looser restrictions let through some more spam or more LTAs, it also blocks less valid users, and there is a larger volunteer pool to manage these issues.  — billinghurst sDrewth 11:09, 4 October 2021 (UTC)

Thanks Martin. I don't believe the editor was blocked for disruption. IIRC they had an entirely productive 6 month (undiscovered socking) tenure, and were blocked due to a violation of the socking policy since they had an active block on an old account. That's a problem the enwiki community should deal with, but the focus here (from my perspective) is the unblock appeal and then the global lock by Amanda.

The unblock appeal was declined for two reasons: 1) global lock evasion; 2) (allegedly) lying about not being related to a specific sockpuppet account. The appeal was declined by a non-CU, and multiple CUs said the alleged account was unrelated, so I think it's safe to ignore 2. 1 creates a bit of a catch-22. I mean here is a comment by another steward saying There is no such thing as lock evasion. To the extent the purpose of locks is to prevent disruption, it's very hard to argue that this account (regardless of whether it should be unblocked on the enwiki project) was actually disrupting the Wikimedia projects.

That aside, how do you suggest an editor in that situation resolve their situation? If the stewards can't deal with the mail queues, and local projects won't consider appeals from glocked editors, and stewards don't unlock accounts unless a local project says it is willing to consider an appeal, are you saying there needs to be a consensus at en:AN or something saying "we will hear an appeal from X editor" before stewards will unlock, and then the editor can appeal, and then they can potentially be unblocked? (I suppose en has UTRS which you might accept, but say for non-UTRS projects). ProcrastinatingReader (talk) 08:55, 8 October 2021 (UTC)

I am quite sure that it is not true that "local projects won't consider appeals from glocked editors". The practice that I have seen, at least on enwiki, is that, if an editor is glocked, they may appeal their block via UTRS, and if a local sysop wants to reinstate TPA, or unblock, the sysop may mail a steward, who unlocks the account as per the request. JavaHurricane 09:03, 8 October 2021 (UTC)

And for other projects: if I recall correctly, most wikis of at least medium size have a mailing list set aside for unblocks, which basically functions like a UTRS. JavaHurricane 09:13, 8 October 2021 (UTC)

Independent from the above discussion about this specific issue, Meta-Wiki really lacks a lot of the definition-related policy and guideline pages that content wikis have, both in terms of local and global actions. We have no specific policies for a majority of actions admins make, and a decent amount of actions that stewards make. It's been something I've been thinking about proposing, specifically for Meta-Wiki local policies (blocking policy, socking policy, rules for editing pages officially organized/affiliated, an actual admin removal policy that isn't just for inactivity, etc.), but that would require significant global community input and a lot of individual work to organize it. I suppose we could make a list of common but officially undefined terms, making sure to note it as a non-policy/guideline essay, to help users unfamiliar with Meta and steward work get along better. Best regards, and happy editing, Vermont (talk) 17:44, 8 October 2021 (UTC)

I'll be happy to assist if needed @Vermont. Camouflaged Mirage (talk) 12:16, 11 October 2021 (UTC)

Global locks needs a fundamental rewrite and there are not many user clear about the proper relationship between local block and global lock. Unfortuanely even I collected a number of cases that global locks may be doubtful, I still have no idea how a formal lock policy should be.--GZWDer (talk) 11:32, 14 October 2021 (UTC)

I don't think we need a global lock policy but yes, I agree the relationship between global lock and local blocks needs to be clearer. Camouflaged Mirage (talk) 09:49, 15 October 2021 (UTC)

Lock evasion? There is no such thing as lock evasion. ~~~~
User:1234qwer1234qwer4 (talk) 17:24, 14 October 2021 (UTC)