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.

Seeking victims volunteers to serve as scrutineers

We have ArbCom elections coming up soon and could use 3 brave volunteers to serve as scrutineers.—CYBERPOWER (Chat) 20:00, 17 October 2024 (UTC)

Hello there, I'm willing to help out. (I have no COI with enwiki) EPIC (talk) 20:01, 17 October 2024 (UTC)

I'm ready to help. Mykola 18:08, 24 October 2024 (UTC)

me too Johannnes89 (talk) 10:15, 25 October 2024 (UTC)

Thank you EPIC, Mykola7, and Johannnes89 —CYBERPOWER (Chat) 14:38, 4 November 2024 (UTC)

Global sysop set audit

Inspired by the above two threads I wrote a PAWS script at https://public-paws.wmcloud.org/46222050/Global%20Sysops.ipynb to review what wikis should be added to or removed from the opt-out wiki set. It suggested:

1. Revoke access on afwiki (14 admins, 9 active)
2. Allow access on anwiki (only 9 admins)

   This wiki explicitly opted out per Global sysops/Local discussions

3. Revoke access on azwiki (15 admins, 13 active)
4. Revoke access on bewiki (10 admins, 7 active)
5. Revoke access on brwikimedia (13 admins, 4 active)
6. Allow access on bswiki (only 9 admins)
7. Revoke access on cowikimedia (13 admins, 3 active)

   (Only if you include both page creations and spam blacklist hits as logged actions, both of which are dubious, probably fine to leave as is)

8. Allow access on cswikisource (only 3 admins)

   This wiki explicitly opted out per Global sysops/Local discussions

9. Allow access on cswiktionary (only 4 admins)

   This wiki explicitly opted out per Global sysops/Local discussions

10. Revoke access on dewikiversity (10 admins, 4 active)
11. Revoke access on elwiktionary (10 admins, 5 active)
12. Revoke access on enwikinews (16 admins, 4 active)

    This wiki explicitly opted in per Global sysops/Local discussions. But personally it's nice to see that enwikinews has recovered above the point of being default in the GS scope after their prior crisis.

13. Remove access on enwikiversity (11 admins, 6 active)

    This wiki explicitly opted in per Global sysops/Local discussions.

14. Remove access on enwikibooks (37 admins, 16 active)

    This wiki explicitly opted in per Global sysops/Local discussions.

15. Remove access on eswikibooks (10 admins, 3 active)

    This wiki explicitly opted in per Global sysops/Local discussions.

16. Allow access on frwikiversity (only 9 admins)
17. Remove access on foundationwiki (25 admins, 5 active)

    This is a special case that doesn't follow standard global sysop rules

18. Remove access on hawiki (10 admins, 8 active)
19. Remove access on hywiki (10 admins, 6 active)
20. Remove access on incubatorwiki (13 admins, 5 active)

    This wiki explicitly opted in per Global sysops/Local discussions.

21. Remove access on itwikiquote (10 admins, 6 active)
22. Allow access on kawiki (only 6 admins)

    This wiki explicitly opted out per Global sysops/Local discussions.

23. Remove access on kkwiki (15 admins, 9 active)
24. Remove access on labswiki (Wikitech): 32 admins, 13 active
25. Remove access on lawiki: 21 admins, 8 active
26. Allow access on loginwiki (only 1 admin)

    This is a special-purpose wiki and isn't subject to GS rules.

27. Revoke access on mediawikiwiki (137 admins, 49 active)

    Please hold pending mw:Topic:Yf8m40ru9m6lvseu

28. Revoke access on nlwikimedia (14 admins, 3 active)

    This is listed at Global sysops/Local discussions as having opted out, but was added to the wiki set out of process in 2022 anyway.

29. Allow access on nlwiktionary (only 7 admins)
30. Revoke access on outreachwiki (20 admins, 4 active)

    This wiki explicitly opted in per Global sysops/Local discussions.

31. Revoke access on pawiki (10 admins, 5 active)
32. Revoke access on ruwiktionary (15 admins, 7 active)
33. Revoke access on sqwiki (11 admins, 4 active)

    There was a very old opt-in request at Steward requests/Global permissions/2010-11#Opt-in for Albanian Wikipedia, not listed at Global sysops/Local discussions. If that's still valid feel free to add it to the /Local discussions page instead.

34. Revoke access on srwiki (15 admins, 14 active)

    This wiki explicitly opted in per Global sysops/Local discussions.

35. Revoke access on swwiki (14 admins, 6 active)
36. Revoke access on testwiki (94 admins, 10 active)
37. Revoke access on testwikidatawiki (38 admins, 3 active)

    Only if you include page creations as logged actions.

    Feel free to ignore the test wikis in general - I know test wikis are a special case, but listing them for completeness. Testwiki is already opted out.

38. Remove access on tlwiki (10 admins, 3 active)

    Only if you include page creations as admin actions

39. Remove access on uawikimedia (19 admins, 6 active)
40. Remove access on ukwiki (49 admins, 39 active)

    This wiki explicitly opted in per Global sysops/Local discussions.

41. Remove access on uzwiki (16 admins, 12 active)
42. Remove access on viwiktionary (11 admins, 4 active)
43. Remove access on wikifunctionswiki (11 admins, 8 active)
44. Remove access on wikimaniawiki (27 admins, 4 active)

Note that in all cases the abuse filter account is treated as an admin, so you may want to skip the ones with exactly 10 admins, and that I didn't look at the state of the wiki more closely than just running the numbers except in a few borderline cases. * Pppery * _{it has begun} 00:59, 31 October 2024 (UTC)

I've opted in the wikis that meet the opt-in criteria with no explicit opt-out discussion.

Regarding the opt-out parts, since all of the wikis above were opted in when the opt-in criteria were met and have not explicitly wanted to opt out, I would likely only want to opt them out if the community explicitly objects to having global sysops. I'm leaving this open for some time in case another steward would like to give a comment on that. EPIC (talk) 10:31, 31 October 2024 (UTC)

For non-content wikis, I'd want to see an actual local discussion - activity can be sporadic depending on what happens to be going on, leaving them in periods with no actual local support. — xaosflux ^Talk 10:40, 31 October 2024 (UTC)

(non-steward comment) I agree with EPIC and Xaosflux. I am not aware that the criteria mentioned on the Global sysops page mean that wikis automatically change status depending on the number of admins. Rather it seems to me that those were the original inclusion criteria for building the list, to be changed later because of local consensuses. -- MF-W 12:50, 31 October 2024 (UTC)

I oppose unnecessary "revoking" of wikis from the global sysop opt-in set, while supporting adding wikis where needed. In the vast majority of cases, there is little evidence that the wiki will be better off without global sysops. Also I've to agree with MF-Warburg - the GS rules could be made clearer as I've seen some global sysops adhere to the conservative interpretation of only working on wikis with less than X active admins. Leaderboard (talk) 13:35, 31 October 2024 (UTC)

system users and bots should certainly not be counted in determining if there are sufficient local admins on a project. (e.g. from above sqwiki says 11, but only has 9 actual people-admins). — xaosflux ^Talk 14:01, 31 October 2024 (UTC)

Why not? The page global sysop mentions no such requirement, and has no mention of the admin count and activity criteria being "legacy" or "historical" as discussed above. And I find the ratchet-style reasoning shown above (you can be automatically opted-in but not opted-out) absurd. Global sysops have a specific defined scope, and of course their usage of the rights should be enforced to only wikis that fall within that scope. * Pppery * _{it has begun} 14:47, 31 October 2024 (UTC)

Global sysops predate system users being flagged as admins, so of course that wasn't considered in the policy. To be a little frank, you are taking a much stronger position on this than the community writ large, and should maybe take a step back and consider who your position is helping and why you would want to continue to push it so hard... – Ajraddatz (talk) 19:42, 31 October 2024 (UTC)

Help with admin policy change

There has been a consensus on ORWP about admin roles and I'm seeking help from bureaucrats to action.

Summary of consensus:

1. An admin is expected to make at least 50 administrative edits in a year.
2. Current admins without 50 administrative edits in the last three years will be removed from their roles, allowing active and experienced Wikipedians to become admins. If a former admin starts active editing contributing to (at least 10) admin tasks then they can reapply to become an admin again.
3. Experienced editors who have not been admins and have been in assisting admin tasks can apply to become new admins.

This consensus will affect two current admins: User:Ansumang and User:Odisha1. On behalf of the community I'll request for removal of their sysop roles. Thanks! Psubhashish (talk) 02:45, 6 November 2024 (UTC)

@Psubhashish Odisha1 already got their admin permissions removed three years ago [1] due to inactivity. Please request removal of admin permissions for Ansumang at SRP#Removal of access, linking your new inactivity policy (and this discussion if you want). Johannnes89 (talk) 19:03, 10 November 2024 (UTC)

Thanks much. Done. Psubhashish (talk) 19:33, 18 November 2024 (UTC)

@Psubhashish: I removed the rights, removed the wiki from the AAR set [2] and updated Admin activity review/Local inactivity policies accordingly [3]. Let me know if I interpreted the policy incorrectly. Also, for transparency, could you perhaps document the inactivity policy somewhere, perhaps at or:ଉଇକିପିଡ଼ିଆ:ପରିଚାଳକ? EPIC (talk) 20:01, 18 November 2024 (UTC)

Thank you, @EPIC. I've updated w:or:ଉଇକିପିଡ଼ିଆ:ପରିଚାଳକ with the details from the consensus. I also noticed that a request for stepping down from adminship shared by another admin (Soumendrak) is still pending. I've updated the same at Permissions#Removal_of_access. Psubhashish (talk) 20:20, 18 November 2024 (UTC)

RFC Notice: Requests for comment/Extract global bot policy to own page

Many parts of Bot policy are written 16 years ago (see here), have little modifications, and no longer in line with current practice. The only thing useful as a policy is the global bot part. So I propose to extract these parts to a new page and then obsolete the current Bot policy. GZWDer (talk) 14:11, 13 November 2024 (UTC)

• A RFC is open at Requests for comment/Extract global bot policy to own page, please comment there. — xaosflux ^Talk 15:07, 13 November 2024 (UTC)

Special:PasswordPolicies for stewards

While browsing that page for other reasons, I discovered S are subject to same rule as an ordinary users, unlike the hardened rules for CU/OS/WMF-OIT/WMF-T&S/Crat/etc etc you name it.

I assume this was because SE requires admin privileges which in turn enforces hardened rules (and loginwiki CU forces them to the hardened rule), I think there is some benefit to using hardened rules for S role by default, unless global group has a special flag enforcing the hardened rule. Thoughts? — regards, Revi 20:44, 16 November 2024 (UTC)

I don't think this is displayed anywhere on-wiki, but the privileged password policy is applied on the steward global group as configured here and here. Taavi (talk!) 21:00, 16 November 2024 (UTC)

Seems like that page is showing the rules for "local groups", while certain global groups (such as stewards) already have enhanced rules. While our stewards are local stewards here on metawiki for technical reasons, they are also global users. Someone could put in a feature request to spin up Special:GlobalPasswordPolicies if they wanted to. — xaosflux ^Talk 23:39, 16 November 2024 (UTC)