Stewards' noticeboard

←Stewards

Stewards' noticeboard

Archives→

Welcome to the stewards ' noticeboard. This message board is for discussing issues on Wikimedia projects that are related to steward work. Please post your messages at the bottom of the page and do not forget to sign it. Thank you.

• This is not the place for stewards requests. To make a new request, see steward requests and requests and proposals .
• For illustration of steward policies and use, see the steward handbook .
• See also: Access to nonpublic personal data policy noticeboard.
• This page is automatically archived by SpBot. Threads older than 30 days will be moved to the archive.

Stewards

• About stewards
• Elections
• History

Requests

• CheckUser information
• Global blocks & locks
• Global rights
• Local bot rights
• Local rights
• Account renaming
• Miscellaneous requests
• URL blacklisting
• Title/username blacklisting

For stewards

• Help
• Policies
• Bugs
• Mailing list
• #wikimedia-stewards^connect

Noticeboards

• Access policy noticeboard
• Stewards' noticeboard

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 2 days and sections whose most recent comment is older than 30 days.

az:Azərbaycan kinosu videoları

Delete page per this discussion. Gadir (talk) 17:10, 8 June 2023 (UTC)

Gadir, it seems the page was turned into a redirect after the deletion discussion. Is that sufficient? (If not, I'd recommend another discussion, as it's been 17 months since the deletion discussion) Best regards, Vermont (🐿️—🏳️‍🌈) 17:26, 8 June 2023 (UTC)

No, this was done because it cannot be deleted. This redirect page is unnecessary and no link to the page, Vermont. Gadir (talk) 17:32, 8 June 2023 (UTC)

@Vermont, how can it be deleted? Need to open a discussion again? Because it doesn't make sense to stay. Gadir (talk) 11:41, 14 June 2023 (UTC)

I think another discussion would be necessary given the time since the previous one. Sorry for the difficulty with this, but I'm not comfortable deleting a page based on a 17 month old discussion. Vermont (🐿️—🏳️‍🌈) 16:57, 14 June 2023 (UTC)

Its ok. I will open a new discussion. Please do not archive this section. Gadir (talk) 22:48, 14 June 2023 (UTC)

Rolling out new design for Kazakh Wikipedia

Hi all! Can anyone help with rolling out the new design for the Kazakh Wikipedia or what should be done locally? As I see it is active for the most local wikipedias. --~~~~ Ashina (talk) 11:14, 12 June 2023 (UTC)

Hello @Ashina: Are you asking to set the new Vector 2022 skin as default skin? In this case you can open a local discussion to obtain a consensus and, in case, get in touch with OVasileva (WMF) (Web Team) for the further steps (task and so on). We, as stewards, can't do much about it. Thanks :) Superpes15 (talk) 11:30, 12 June 2023 (UTC)

Also cc @SGrabarczuk (WMF): SCP-2000 15:18, 12 June 2023 (UTC)

It's of course always possible to activate the new Vector 2022 skin for yourself, e.g. at Special:GlobalPreferences#mw-prefsection-rendering. Johannnes89 (talk) 18:32, 12 June 2023 (UTC)

Great! Thank you a lot for the update. So we need to discuss and make a resolution? Is there any time slot supposed to be allocated for that? I believe no one would be against new design skin!?Ashina (talk)

Temporary removal GIPBE from Q28

Hello, stewards.
Recently, we found a user Q28 (talk · contribs) disruptively edited on lots of projects, including Chinese Wikipedia, English Wikipedia and WikiCommons. Sysops on these projects have imposed their blocks. I hereby sincerely ask for a temporary removal of GIPBE access from Q28, since their behaviours are really kinds of losing trust on different communities.
BTW, they said they will start edit on Wikidata just after blocks being imposed on Wikicommons. Lemonaka (talk) 13:57, 20 June 2023 (UTC)

If they do not have IPBE they will not be able to edit, which will be tantamount to an indef across all projects. On English Wikipedia they are only partially blocked, and if they cannot edit because of not having IPBE (global or otherwise) it will be hard for them to demonstrate positive editing behaviours. Primefac (talk) 14:19, 20 June 2023 (UTC)

 Support removing GIPBE as Commons blocking admin. Yann (talk) 14:29, 20 June 2023 (UTC)

Hello @Lemonaka, @Yann and @Primefac, thank you for bringing this to our attention. I went ahead and removed the GIPBE permission from Q28 for loss of trust, as demonstrated by numerous active blocks. This removal is intended as a indefinite one; GIPBE can be regained by making a new request at SRGP. I'll send a removal notification as well. Sincerely, Martin Urbanec (talk) 14:38, 20 June 2023 (UTC)

I looked into Q28's blocks on enwiki and commons a little bit and found they had the same intrinsic problem as the block on zhwiki. Loss of trust is correct in this case is correct. We have given Q28 so much time to demonstrate any possible positive behavior but failed. Tiger (talk) 00:38, 21 June 2023 (UTC)

by the way the users phabricator accounts [1][2] have been disabled as well recently [3] Johannnes89 (talk) 06:47, 21 June 2023 (UTC)

Thanks. @Johannnes89 Good disable after checking the tickets they created. Lemonaka (talk) 08:02, 21 June 2023 (UTC)

Per Tigerzeng 's comment and Q28 recent behaviour on different wikis, I believe they are lack of competence and impossible to demonstrate any possible constructive behavior. Thus, I submitted a global lock request. Thanks. SCP-2000 09:21, 21 June 2023 (UTC)

@Martin Urbanec and SCP-2000: Also Q288 (talk · contribs), which is an alternative account of Q28 per their userpage (and also zh:User:28Q and zh:User:Q28bot per their user page in zhwiki). 132.234.228.168 11:05, 21 June 2023 (UTC)

Removed as well, thanks for the ping. Martin Urbanec (talk) 16:44, 21 June 2023 (UTC)

Gitz6666 global lock discussion

Dear Stewards, could you see your way clear to undoing the global lock placed on User:Gitz6666's account?

Following the discussions at the Signpost and elsewhere, it has become abundantly clear – in my view at least – that this situation would never have arisen if Italian admins had not circled the wagons around a biography of en:Alessandro Orsini (sociologist) that was one-sided and – again in my view, having researched the available academic sources – incompatible with BLP policy.

Moreover, given everything that has been said on and off wiki, it appears that Gitz6666 in the first instance merely communicated material that was openly available on-wiki and in a second instance followed advice received and raised COI concerns privately with an admin. There appears to be no public or private evidence that Gitz6666 did any more than that. On the other hand, I find there is ample evidence suggesting that Gitz6666 had the best interests of the project at heart.

Gitz6666 has around 7500 contributions and a clean block log on English Wikipedia. I feel the global lock by User:Sakretsu was a significant overreaction, taken by a steward who would have been better advised to delegate the decision to one of their colleagues whose home wiki is not the Italian Wikipedia (cf. salient comments by User:HaeB in the Signpost discussion).

Regards, Andreas JN466 22:47, 2 July 2023 (UTC)

@Jayen466 thank you for the note, as noted at w:en:Wikipedia_talk:Wikipedia_Signpost/2023-06-19/In_the_media, there is currently an active appeal under private review. — xaosflux ^Talk 23:06, 2 July 2023 (UTC)

The first public acknowledgment of the appeal was sixteen days ago, on the 21st of June. This suggests that the case evidence is not very strong as if it were the glock would have been confirmed quickly. Can you give us an idea of the deadline you've set for yourselves to announce your decision? SashiRolls (talk) 08:01, 7 July 2023 (UTC)

After internal discussion and review of available evidence, stewards have decided to accept Gitz6666's appeal.--Sakretsu (炸裂) 16:33, 7 July 2023 (UTC)

Review of ability to edit local special:AbuseFilters with new global application

Hi to all. With the success of Requests for comment/Make global abuse filters opt-out and now its implementation, I think that it is time to review the access to local abuse filters, and the global abuse filters, or at least the scope. There will need to be a team of competent people able to play in the space of abusefilter-modify-global, especially as we transition to large wikis getting hits on filters that are less designed for large wikis, and definitely not been customised. In fact some filters were written knowing that the large wikis were not within scope.

I think that it is time to look to create a local group Global abuse filter-editors with two of the three rights that local administrators have to create those filters (per mw:Extension:AbuseFilter). No need for restricted rights as we don't apply restrictive actions on global filters.

[We could even consider that we can remove the global components from meta admins by default and move to this approach to allow the community that fuller control, though that would be a solution in search of non-existing problem, just the potential.]

IMHO these global abuse filters were given to stewards, and these rights have moved (dribbled) further and further in drip feeding rights, and independently the use. There needs to now be the clarity on where these rights and the filter management belongs.

data

special:listgrouprights

• local admins
  • Create or modify abuse filters (abusefilter-modify)
  • Create or modify global abuse filters (abusefilter-modify-global)
  • Modify abuse filters with restricted actions (abusefilter-modify-restricted)
• stewards
  • Create or modify global abuse filters (abusefilter-modify-global)

I feel that we need to put these more broadly before the community, and they need to be able to be managed independently of metawiki administration. Before I more firmly put this out into the wild, I would appreciate any thoughts and conversations that you can make public about the PoV of stewards.  — billinghurst sDrewth 03:27, 7 July 2023 (UTC)

there is Meta:Requests for comment/Create local meta abuse filter helper and abuse filter manager role --Johannnes89 (talk) 06:48, 7 July 2023 (UTC)

Are the existing global groups "abuse filter helper" and "abuse filter maintainer" not sufficient for this task? --MF-W 10:39, 7 July 2023 (UTC)

Think the core question here is really: should metawiki admins have global filter access revoked? Is there an identified problem with that today? — xaosflux ^Talk 10:44, 7 July 2023 (UTC)

This seems to repropose Meta:Requests for comment/Create local meta abuse filter helper and abuse filter manager role, which is under discussion (and as of now, unlikely to pass). I don't really see a problem that could be resolved by introducing a new group. I can't imagine a case when I would trust someone to edit the global filters, but at the same time not edit the Spam blacklist (and thus oppose Meta local adminship) or edit the local filters to help resolve issues there (and thus oppose granting AFM).

Creating local filter maintaining group could make sense if we want to stop treating Meta admins as a sui generis global role (despite having only Meta rights, Meta admins can affect all Wikimedia projects [and third party installations] by editing the blacklists that are centralized on Meta). However, this setup doesn't seem to be problematic (please let me know if I missed something) and even if it was, creating only the filter maintainers group wouldn't solve it. Martin Urbanec (talk) 10:49, 7 July 2023 (UTC)