Stewards' noticeboard/Archives/2024-09

Please do not post any new comments on this page. This is a discussion archive first created in September 2024, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

abusefilter-log for GR / GS?

Latest comment: 3 months ago11 comments7 people in discussion

Hi, @ShifaYT noticed that global groups who are allowed to see abuse filter details usually have abusefilter-log and abusefilter-log-detail permissions (per Special:GlobalGroupPermissions AFH, AFM, founder, Omb, staff, stewards, sysadmins and researchers). But for some reason global rollbacker and global sysops only have abusefilter-log-detail without abusefilter-log. I don't think it makes a difference, because both permissions seem to be a default right available to all local users (see e.g. en:Special:ListGroupRights). For the sake of completeness I'm proposing to add abusefilter-log to GR and GS. Any objections? Johannnes89 (talk) 06:05, 5 September 2024 (UTC)

That's already in the (*) group by default, just like (read) - have any projects actually asked for an overrider to remove this? — xaosflux ^Talk 09:02, 5 September 2024 (UTC)

I'm not aware of any projects not using the default of abusefilter-log in the (*) group. I was just proposing it to avoid any confusion (most global groups have this specific right, while it's not checked for GR and GS). Johannnes89 (talk) 14:17, 5 September 2024 (UTC)

For example, not everyone on itwiki has abusefilter-log. I am a GR but cannot see filter logs there. Syunsyunminmin 🗨️talk 14:22, 5 September 2024 (UTC)

Some wikis do override this. The biggest ones that come to mind are the Italian and Dutch Wikipedia. A few others do something similar, but only for viewing abuse filters. I'd

Support this change. - XXBlackburnXx (talk) 14:24, 5 September 2024 (UTC)

Ahh wasn't aware that some projects changed this. Apparently both itwiki and nlwiki require users to be in the autoconfirmed group for abusefilter-log (GR have autoconfirmed rights, but that doesn't put them in the autoconfirmed user group). And if a user with GR/GS permissions doesn't meet local autoconfirmed requirements (e.g. itwiki requires 50 edits) they cannot access abuse logs missing abusefilter-log, even though they have abusefilter-log-detail. Johannnes89 (talk) 14:48, 5 September 2024 (UTC)

Well, if some projects are overriding this, I'm fine adding back in for GS's. — xaosflux ^Talk 15:12, 5 September 2024 (UTC)

I wonder whether this is the same for AFM? I had requested it at Steward requests/Miscellaneous/2022-06#Add spamblacklistlog to AFM previously but it was declined on the basis of redundancy at that time. ~~~~
User:1234qwer1234qwer4 (talk) 00:59, 7 September 2024 (UTC)

Done as per no objections for a week. EPIC (talk) 12:20, 12 September 2024 (UTC)

Thank you very much. نوفاك اتشمان (talk) 14:24, 14 September 2024 (UTC)

This section was archived on a request by: Johannnes89 (talk) 16:29, 13 September 2024 (UTC)

abusefilter-modify-restricted for GS?

Latest comment: 3 months ago10 comments5 people in discussion

Special:GlobalGroupPermissions/global-sysop currently has sysop-level permissions related to abuse filters, but for some reason not the permission to edit or create filters that block users. For example, I cannot attend to a filter on the (as-of-recent-GS-wiki) Serbian Wikipedia which I have been discussing and proposing changes to with a srwiki administrator lately. An additional hypothetical use case could be disabling an erroneous filter with block privileges created by a local admin, and potentially just using the block functionality on wikis without active sysops. Any objections? ~~~~
User:1234qwer1234qwer4 (talk) 01:26, 7 September 2024 (UTC)

No issues, sounds sensible. Leaderboard (talk) 04:51, 7 September 2024 (UTC)

Support IMHO, global sysops should have full access to local abuse filters on the GS wikis. --نوفاك اتشمان (talk) 11:12, 7 September 2024 (UTC)

Does this not depend on the wiki though BTW? For example some wikis have opted not to allow blocking for abuse filters, such as en.wiki. Leaderboard (talk) 11:31, 7 September 2024 (UTC)

Even there sysops have abusefilter-modify-restricted (presumably for "strip autoconfirmed" actions). I don't think the right will override such wiki-specific restrictions (though feel free to prove me wrong). ~~~~
User:1234qwer1234qwer4 (talk) 13:08, 7 September 2024 (UTC)

Looking at it further, doesn't it require a phab change to enable blocking? As a result, "just using the block functionality on wikis without active sysops" won't be of use unless that wiki has blocking enabled. Leaderboard (talk) 13:35, 7 September 2024 (UTC)

Ah, didn't know it's opt-in rather than opt-out. I do remember trying to update deprecated filter parameters on some small GS wiki in 2022 and not being able to, though. That said, the "Revoke the user's autoconfirmed status" checkbox (which is default I think?) still can't be ticked, as I just verified on test2wiki. ~~~~
User:1234qwer1234qwer4 (talk) 14:06, 7 September 2024 (UTC)

Done as per no objections for a week. Courtesy ping @1234qwer1234qwer4 and نوفاك اتشمان:. EPIC (talk) 10:19, 14 September 2024 (UTC)

Thank you very much. نوفاك اتشمان (talk) 14:21, 14 September 2024 (UTC)

This section was archived on a request by: Johannnes89 (talk) 11:59, 14 September 2024 (UTC)

Allow global bots to run on SqWiki

Latest comment: 3 months ago3 comments2 people in discussion

A few days ago, I was notified that the Albanian Wikipedia (sqwiki) does not allow global bots to operate without prior approval. Following this, we held a community vote, where the consensus was to allow global bots. As I mention in the initial discussion, our community is relatively small in terms of human resources, and we are generally supportive of automation and external assistance. Adding on that, there is a concern that a request for approving a global bot could go unnoticed for extended periods due to the limited number of active editors. To address this, we believe it would be more efficient to allow global bots by default, with the simple condition that we are notified through our bot venues whenever a global bot begins operation on our project. This will enable us to track active bots and assign appropriate flags to ensure they are not hindered by our edit filters. - Klein Muçi (talk) 09:36, 18 September 2024 (UTC)

Done. EPIC (talk) 09:46, 18 September 2024 (UTC)

This section was archived on a request by: EPIC (talk) 09:46, 18 September 2024 (UTC)

phab:T25310

Latest comment: 3 months ago7 comments3 people in discussion

I would like to check with the stewards on whether it's worth my writing a bot to attempt to fix this bug for existing usernames (and after that, perhaps fix it as stewards suppress usernames in case MediaWiki:Gadget-globalSuppress.js isn't used, as this does tend to cause confusion for admins and patrollers). Asking in advance since I will require some sort of global suppression rights eventually, so there is no point if that cannot be given. Please ping me in a response. Leaderboard (talk) 07:48, 1 September 2024 (UTC)

@Leaderboard: sorry but this is 99% a non-starter, global suppression rights cannot be given out for testing. Just my 2c and we will discuss at the next stewards' meeting, but the answer is probably no. – Ajraddatz (talk) 19:23, 1 September 2024 (UTC)

@Ajraddatz Not testing (I could use the cluster for that even if that would be messy), but at the end. Or a steward runs the bot or whatever - but this kind of shows the difficulty non-stewards have in fixing such issues. Leaderboard (talk) 04:27, 2 September 2024 (UTC)

Same for not testing. The OS policy has no provision for global OS access or even a series of local accesses that could do what you want it to. I want to put this lightly, because I do appreciate the desire to help out... but problems like these can't be resolved by a non-steward. We have a close working relationship with WMF staff for this reason, to get technology solutions respecting our tools that cannot, either technically or effectively, be made by volunteers. This issue is quite low priority, as there is a script that can be used as a workaround and the problem is relatively rare anyway. – Ajraddatz (talk) 04:57, 2 September 2024 (UTC)

@Ajraddatz Fair, but the only problem is "the problem is relatively rare anyway" is false - just take a look at Global_statistics/Rank_data/enwikinews to see multiple examples of suppressed accounts (to give an example) and it's an issue I regularly hit as a patroller. P.S: I do have full oversight access in the beta cluster - just clarifying "Same for not testing". Thanks for answering BTW - looks like the only recourse is my being a steward from what I understand. Leaderboard (talk) 05:00, 2 September 2024 (UTC)

A "fix" for that should be technical, or perhaps technical + a maintenance script run; certainly not a volunteer's bot to go around to hundreds of project suppressing things. — xaosflux ^Talk 13:05, 9 September 2024 (UTC)

A technical fix is ideal, but in the absence of one, I don't see the issue with a properly tested, authorised and vetted "volunteer's bot to go around to hundreds of project suppressing things". Leaderboard (talk) 13:18, 9 September 2024 (UTC)

Discrepancy between Meta and local projects on global bots

Latest comment: 3 months ago7 comments3 people in discussion

Hi, I've been working on getting my bot (Global reminder bot) approved on multiple wikis, and one source of confusion I've repeatedly run into is with respect to global bots. At some time in the near future, I expect to submit my bot for global bot approval (as per Global bots), and naturally, I would rather focus my time on getting approval for wikis that are in the opt-out set. The problem is that I've seen multiple wikis whose bot policy seems to reference the pre-2022 rules for global bots, which only allowed its use for fixing double-redirects and maintaining interwiki links. To give an example, here's what the Russian Wikipedia (which is not in the opt-out set) says:

ru:Википедия:Заявки_на_статус_бота says that "If your bot has global bot flag, then there is no need to submit a local request unless you decide to perform new tasks not specified in the terms of a global flag usage"
but ru:Википедия:Правила_применения_ботов (both a machine translation of the Russian version, and the "official" English translation) say that "The actions of global bots in the Russian section are limited to fixing double redirects".

The Meta policy says that it's an official cross-project policy, which should mean that global bots should be OK to run on these wikis (it only says about respecting preference with respect to marking edits as bot). The other point worth noting is that even en.wiki is not on the opt-out set, but it's pretty clear that they don't allow global bots except for fixing double redirects.

I'm a bit stuck on how to proceed here. The "safest" way would be to manually request bot flags on all of these wikis, but it is rather difficult to check all wikis on what their policies are (assuming they have one in the first place), especially given how rarely it is expected to edit on average - I don't know whether Wikidata is enough, and plus it makes adding newly-created wikis a bit more complicated. Thanks in advance, and please ping me in a reply. Leaderboard (talk) 10:33, 7 September 2024 (UTC)

Currently many wikis have a outdated copy of global bot policy. I will propose that for every global bots wikis, the (section of) bot policy concerning global blocks should become non-normative unless the local community decided to explicitly restrict usage of global bots. GZWDer (talk) 19:16, 8 September 2024 (UTC)

I will further propose that global bots are only opt-out on wikis that they explicitly opt-out. However this will require an RFC and also notification to ~100 wikis current not enabled global bots (which will no longer opt out unless they decided to opt out). GZWDer (talk) 19:21, 8 September 2024 (UTC)

I support both proposals. Leaderboard (talk) 08:43, 9 September 2024 (UTC)

For global reminder bot, an alternative is notify the user in Meta user talk page when there are user groups to expire in any wiki. This does not need any further approval since notification is at Meta, and users will still be notified if they enabled cross-wiki notification (which is enabled by default).--GZWDer (talk) 19:24, 8 September 2024 (UTC)

This is doable (and may be implemented in wikis such as Wikidata where their bot policy by default prohibits bots from posting on user talk), and is something I thought about, but it is not something I want to implement at a widespread level, because

while almost certainly the case, it cannot technically be assumed that someone has a Meta account, and
while users will normally be notified by email, I think many users will miss a message that is not at their homewiki, and
this circumvents local wikis' preferences on the use of this bot, which I don't like. For example, some wikis explicitly do not want the bot running on their wiki, and I can only find that out by following the policy (or asking).

Leaderboard (talk) 08:45, 9 September 2024 (UTC)

The global bot policy never overrides a more restrictive local policy; violating any local bot policy is likely to land you with local blocks; for any questions about a local policy - you should ask that local community. Where we may be able to help is if there is a project that had a local community which has completely disbanded. — xaosflux ^Talk 20:13, 8 September 2024 (UTC)

U4C announcement regarding user rights

Latest comment: 3 months ago1 comment1 person in discussion

Hello stewards and page watchers, the U4C has added its first announcement seeking feedback on the proposed list of local and global rights for the group. Your feedback is welcome! The intent is to do a formal vote after the community consultation. – Ajraddatz (talk) 23:31, 13 September 2024 (UTC)

Need for fair human arbitrage

Latest comment: 3 months ago18 comments4 people in discussion

Rigid automated guidelines mandated that I lost my username in SUL finalization.

The situation that arose, is that the username I had, now ended up being owned by a dead account that hasn't been touched in 12 years (see: my efforts to get in contact 2 years ago).

I immediately disputed the automated decision to take away my Sol username in favor of the dead account. I'm an active user and Sol is a personal brand of mine, that took 15 years to build and is known across the internet.

I want my Sol username back, please.

(See: the discussion arguments so far) --Sol451 (talk) 07:47, 9 September 2024 (UTC)

Repeatedly making your request in multiple venues will not change the outcome. ~~~~
User:1234qwer1234qwer4 (talk) 12:57, 9 September 2024 (UTC)

User appears to have escalated the decline from the prior link. Making an appeal isn't completely out of line. That certainly doesn't mean that their underlying argument has merit. — xaosflux ^Talk 13:01, 9 September 2024 (UTC)

Dear @1234qwer1234qwer4,

Your statement assumes, that my arguments were evaluated on their merit. I appeal because my arguments were only bypassed, people didn't have the authority, not their responsibility, go elsewhere (many times), etc. etc. Mechanical reasoning based on the flawed metric of "edits" does not do justice to my case. It's just mental laziness.

I'd like someone to really look at the merit of my arguments and fairly evaluate the interests of the persons involved and explain why one argument would have more merit over the other one. Sol451 (talk) 10:37, 10 September 2024 (UTC)

The normal venue for arguing for a usurp is Steward_requests/Username_changes#Requests_involving_merges.2C_usurps_or_other_complications; have you already requested there? — xaosflux ^Talk 13:06, 9 September 2024 (UTC)

During SUL finalisation multiple people happened to have local accounts named "Sol", but of course only one global account with that name can exist. That's why multiple users with the previous name "Sol" got notified about them being renamed, e.g. [1][2][3]. The account with most edits got to keep the original user name, which is dewiki user Special:CentralAuth/Sol with 1,670 global edits, while Sol451 got renamed just like the other local users called "Sol" due to having fewer global edits (258 global edits today). This has been explained multiple times and given that USURP is inadmissible for accounts with valid edits, there is no way we can grant them their previous user name. --Johannnes89 (talk) 13:59, 9 September 2024 (UTC)

Thanks for the research there @Johannnes89! — xaosflux ^Talk 15:25, 9 September 2024 (UTC)

Dear @Johannnes89 thank you for compiling the list of all the places I tried to object to my mandated name change. I tried not to bypass any level before I got here. I couldn't access all the items in your list (especially the tickets), and would like to see what was written about me in those inaccessible entries. I tried to keep my appeal brief, please see my elaboration of arguments below. Sol451 (talk) 09:40, 10 September 2024 (UTC)

The tickets contain email communication between you and the stewards / support-team in 2015 and 2024, so you should have those mails yourself. I just linked them in case other stewards are not aware of those prior conversations. Johannnes89 (talk) 09:44, 10 September 2024 (UTC)

Now that I know what USURP means, you wrote an interesting thing: "USURP is inadmissible for accounts with valid edits", but that is exactly what happened with me. My username was forcefully taken away, whilst my account had valid edits. Sol451 (talk) 09:50, 10 September 2024 (UTC)

That policy talks about current requests by other users. Your username had to be changed for technical reasons as part of SUL finalisation (which has been completed and no longer needs to be reflected in policy). ~~~~
User:1234qwer1234qwer4 (talk) 10:43, 10 September 2024 (UTC)

Exactly. During SUL finalisation even accounts with valid edits got forcefully renamed if multiple local accounts with the same name existed and only the user with the most edits got to keep it, because there can only be one global account with that name. Today with SUL finalization finished years ago there is no policy which allows usurpation just because a user is inactive (except when they have zero or close to zero valid edits). Johannnes89 (talk) 11:00, 10 September 2024 (UTC)

I immediately objected to and am still disputing the automated decision that took place during SUL finalisation, that my account with valid edits got forcefully renamed. As I pointed out then and you can even see more clearly now in hindsight, that the automated decision was wrong, for the reasons that I provided below. I'm kindly asking to mend this situation by undoing the automatically forced rename of a live account and rename the dead account instead. Sol451 (talk) 07:18, 17 September 2024 (UTC)

Endorse decline, we're not going to forcibly rename that account with >1000 edits on a content project now. — xaosflux ^Talk 15:27, 9 September 2024 (UTC)
Dear @Xaosflux,

Nobody else is being forced, because everybody was asked and nobody objected except for me. So the only one that is being forced is me. I strongly object against forcefully taking away my username.

Nobody weighted the merit of my arguments. All I got so far is mechanical reasoning, based on the flawed metric of "edits". I'm asking to look beyond that and really weigh my arguments against the complaints of the current holder of the Sol username, if any.

Everybody talks about USURP, but I don't know what USURP means? I'm NOT asking for the current holder of the Sol username to be deleted, just to add a small demarcation to the username of the dead account like Sol(DE) for example.

I tried to contact that user 2 years ago, but the account doesn't respond to anything. The account hasn't been touched in 12 years (that's the time a newborn grows up to puberty). It was already a dead account when SUL finalization took place. So the user apparently lost interest or doesn't care to object to resolving a username conflict.

Regarding the flawed metric of "edits". I'm the writer of a WikiBook. It took many hours and countless edits to put down my experience. That editing mostly wasn't done on-line. Editing was done off-line, in other environments and then uploaded to the book. On the other hand, I tried looking up the edits of the other Sol username holder and most of the time couldn't find them. The ones I did manage to find, appeared to be little in volume. The metric of "edits" for my WikiBook contributions is not comparable to the metric of "edits" by the Sol holder in WikePedia articles. The volume of my work is greater that his volume of work. Although the metric of the number of "edits" of the Sol holder is higher, his volume of work is smaller than mine.

It seams you have already made up your mind and "endorse decline", but please look beyond mechanical reasoning based on the flawed metric of "edits" and really weigh all of the interests of the persons involved. Sol451 (talk) 09:22, 10 September 2024 (UTC)
"Usurp" simply means to forcibly take something from somewhere else (in this case to take a username away from whomever could be in control of it now). Keep in mind, accounts do not have to be used to add contributions, some people use accounts for many read-only purposes. This is a discussion, so while I endorse the prior decline of your request - others could disagree. — xaosflux ^Talk 09:27, 10 September 2024 (UTC)
Dear xaosflux,

You wrote: "Keep in mind, accounts do not have to be used to add contributions, some people use accounts for many read-only purposes.".

That's why I contacted that user 2 years ago if he is still using the Sol username, but he never replied.

Does 12 years of inactivity hold more merit than an active user? Sol451 (talk) 10:00, 10 September 2024 (UTC)
You can use an account for more than just contributing, many people use an account just for reading. There is no way to tell, and there is no requirement that anyone respond to queries. Also, some people are idle for many many years, to one day return. — xaosflux ^Talk 10:06, 10 September 2024 (UTC)