Stewards' noticeboard

Hello watchers of SN, we are doing a public consultation on global account blocking guidelines! Come see at Requests for comment/Global account blocking practices. Stewards who didn't participate in the internal discussion are welcome to comment of course (and those that did). – Ajraddatz (talk) 18:13, 25 August 2024 (UTC) Reply

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) Reply

@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) Reply

@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) Reply

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) Reply

@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) Reply

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) Reply

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) Reply

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) Reply

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) Reply

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 Support this change. - XXBlackburnXx (talk) 14:24, 5 September 2024 (UTC) Reply

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) Reply

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

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) Reply

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) Reply

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

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

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) Reply

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) Reply

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) Reply

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) Reply

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) Reply

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) Reply

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) Reply

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) Reply

• Stewards
• Noticeboards