Steward requests/Miscellaneous

Shortcut:
SRM

This page is for Wikimedia wikis having no active administrators. Requests can be made here for specific administrative actions (such as page deletion) to be performed by a steward or global sysop. In other cases:

If the wiki does have active administrators, file the request with one of them.
If the wiki has an active editor community, any potentially controversial action (deletion of actual content, edit to a protected page, renaming of a protected page, etc.) should receive consensus from the wiki community before being requested here, and a link should be provided to that consensus in the request.
For global lock/block requests, file a request at Steward requests/Global.
For non-controversial deletion requests such as empty page, simple spam or vandalism, and non-controversial or emergency requests to block vandals, spammers or other malicious users, you may use global sysop requests instead.
If a consensus is considered required to act, similar principles apply as expressed at Steward requests/Permissions/Minimum voting requirements, and can be used for guidance to how and what should be done at small and medium communities to gain a consensus.

To add a new request, create a new section header at the bottom of the "Manual requests" section using the format below:

=== Very brief description of request here ===
{{Status|In progress}}
Give details about your request here. --~~~~

It is helpful if you can provide a link to the wiki (or the specific page on the wiki) in question, either in the header or in the body of your request.

When reporting cross-wiki vandalism, the following template calls can be used to link to a user's contributions across all Wikimedia content wikis (these are for logged in users and non-logged-in users, respectively):

* {{sultool|Username}}

* {{luxotool|IP.address}}

Template {{LockHide}} can also be used in appropriate cases.

To request approval of OAuth consumers please use {{oauthapprequest}} (see the documentation before using).

Old requests are archived by the date of their last comment.

Cross-wiki requests
CheckUser information Global blocks/locks Permissions (global) Permissions (bot) Permissions (other) Username changes/ usurpation requests Miscellaneous requests URL blacklisting Title/username blacklisting Email blacklisting
Meta-Wiki requests
CheckUser information Deletion Permissions Requests for help

Bot-reported requests

See Global sysops/Speedy delete requests.

Manual requests

Create and configure a new wikiset

Status: In progress

Per the guidance provided in phab:T417505#11618361 I would like to request a new wikiset to be created, similar to the existing wiki set titled "Opted-out of global bots". This new wikiset should be called "Opted-out of global IP block exemption" and should be an opt-out based set. As a start, fawiki should be listed as a member. Special:GlobalGroupPermissions/global-ipblock-exempt should then be modified to use this wikiset. Huji (talk) 02:53, 16 February 2026 (UTC)[reply]

For the record, there is a relevant discussion at SRGP/2025-11 § Global IP block exempt for GodNey (revoke). NguoiDungKhongDinhDanh 03:16, 16 February 2026 (UTC)[reply]

Oppose GIPBE only bypass global IP blocks and rangeblocks, and it does not affect local IP blocks and local rangeblocks. 🪶-TΛNBIRUZZΛMΛN (💬) 03:30, 16 February 2026 (UTC)[reply]

"users who know English and can navigate Meta would have a higher likelihood of getting around proxy blocks by way of GIPBE" sounds out of touch: GIPBE is usually granted only to established users. Besides, local policy should not prevent blocking the proxy IPs used by sockpuppet suspects found during CU (as a way to force them apply for local IPBE). Is there local concensus for the change you propose? Srapoj (talk) 06:09, 16 February 2026 (UTC)[reply]

I'm a bit hesitant to this, mainly because a) this right is already quite sparingly granted to users who are deemed trusted, and b) the purpose of this right is to be truly global to allow such users who have a need to edit from globally blocked IPs. If fawiki has a compelling reason to opt-out of this group, it should likely at the least go through a community discussion, similarly to how we require communities to start discussions for opting in/out of, for instance, global sysops. EPIC (talk) 06:29, 16 February 2026 (UTC)[reply]
Oppose: This is a global right that by the global community. A single project cannot change this; it must be changed by a global RFC. 𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 (WikiBayerCatHelper) 16:20, 16 February 2026 (UTC)[reply]

@Huji, what makes fawiki special enough that it needs to be excluded from GIPBE (I did review the phabricator thread and it does sound a bit odd that you're forcing these users to take risks)? Also I thought that you already block proxies like enwiki does. Leaderboard (talk) 16:43, 16 February 2026 (UTC)[reply]

A couple responses:

Can local communities still block users from using proxies? Yes, but that means they need to import all proxy blocks locally. The purposes of global blocking proxies is, partly, to avoid every project having to initiate, extend, and manage thousands of proxies blocks.
Why is fawiki special? It isn't special. However, because most editors in fawiki are from Iran (where many websites are blocked by the government) and most of them use proxies for other internet browsing, many of them find themselves blocked when accessing Wikipedia. It may be an inconvenience for them to turn off proxy when editing Wikipedia, but we want CU data to be reliable, therefore we expect them to accept the inconvenience, and we sparingly offer local IPBE. By issuing GIPBE, Stewards are ignoring the wishes of the local community.
With that said, I would argue any project with active local IPBE process should be allowed to be exempted. Cross-wiki users can request local IPBE on those projects, allowing the local community to assign this right. A list exists in No_open_proxies#Local_exceptions but Stewards do not consult with or defer to those projects when issuing GIPBE.
What if this proposal gets declined? Then the only remaining solution would be for a bot to constantly import proxy blocks from meta into fawiki.
Do stewards issue GIPBE for its intended purpose (that is, for crosswiki editors who are stuck in IP blocks across many projects)? Not always. There are many cases of GIPBE being granted to a user who (aside form Commons), really only edits in one Wikipedia or a couple. Those users should be directed to the local IPBE processes of said wikis, but an attempt to convince Stewards to do so has also failed.

If Stewards neither agree to a wiki-based exemption, nor to a process in which they involve local communities and limit GIPBE to truly cross-wiki editors, then I would like that to be made known here so I can pursue alternatives through phab:T417505 and/or mass importing global blocks into local wikis. Huji (talk) 18:06, 16 February 2026 (UTC)[reply]

Neutral. On one side, I don't want to limit the right of a project to do what it wants, and if it involves GIPBE, so be it. On the other side, I still think this is a bit heavy-handed (after all, you need to think from the user's point of view - why should they have to unnecessarily apply for rights on multiple projects? A criticism also applicable to en.wikipedia), but again not my call to take. Leaderboard (talk) 19:16, 16 February 2026 (UTC)[reply]

I don't really understand why a project would trust stewards to effectively globally block open proxies, but not effectively grant exemptions to those global blocks on an as-needed basis. All options presented are concerning absent information on the problem - have there been a number of cases where non-trusted users were granted GIPBE? If so, maybe stewards should be more restrictive in who is granted those permissions, particularly if those users are active on fawiki. Do fawiki admins lack capacity to deal with vandalism and abuse? Out of approx. 1250 users with GIPBE, presumably only a handful are active on fawiki - are local admins not able to block problematic users with GIPBE? If this is a case of one user being granted GIPBE who misused the permission, that doesn't seem to build a case for fundamental change to me. – Ajraddatz (talk) 22:13, 16 February 2026 (UTC)[reply]
Great questions, Ajraddatz. The reason for the first part is that blocking proxies is an agreed upon process on all wikis (and Stewards doing it centrally makes sense), but deciding to whom to give the exception is a subjective decision. One is agreeable by all, the other is debatable.

The answer to your second point about whether fawiki admins can block vandals is: the concern isn't with overtly vandal users. The concern is with the user type who is a sockmaster, causing conflicts without crossing the line. If we establish they are a sock via CU, we can block them. If the CU data is tainted because they were allowed to use proxies, we cannot. That is why we don't want GIPBE to be granted to users who aren't truly cross-wiki (i.e., doing hundreds or thousands of edits across many different projects). But, as I stated before, an attempt to create a guideline for Stewards to do exactly what you said ("be more restrictive in who is granted those permissions") was tried and failed.

Not to make this political, but one could argue the Stewards have no skin in the game if a sock master causes conflict in a project on which they are not active. But Stewards could feel like their power is being taken away by way of a restrictive guideline or a restrictive wikiset config. This imbalance may explain why every effort to try to limit the GIPBE process fails. Huji (talk) 22:49, 16 February 2026 (UTC)[reply]

Appreciate the follow up, and I can understand your frustration given you have raised the issue before. I am still a bit worried about the implications of stewards being able to issue a global block but not able to exempt people from it - particularly if multiple wikis are added to the opt-out set. It would create an onerous series of bureaucratic hoops for a user impacted by a global block to go through, and since the vast majority of users with GIPBE are not disruptive, I am not sure of the benefit vs the cost. I'm also not sure that your hands are as tied as you think they are in cases where someone is being disruptive but not a CU confirmed sock - you can still block or warn them for disruption, and ultimately there are easier ways for someone intent on causing disruption to mask their true IP address than editing through a proxy and requesting GIPBE.

All that said, I do think that stewards could be more restrictive in handing out GIPBE in cases where the requester is only active on one wiki. I'm not sure I agree with your thresholds below - 500 edits is more than most accounts make overall and Wikidata and Commons are two projects where people are typically somewhat active in addition to their home project. But the point is taken that a lot of users end up with GIPBE without having a significant history of cross-wiki editing. I will try to think more about that myself in my own GIPBE granting, and encourage other stewards to do the same. – Ajraddatz (talk) 18:49, 17 February 2026 (UTC)[reply]

@Ajraddatz I appreciate your thoughtful response, your willingness to understand a different point of view, and your commitment to change your approach and encouragement to others to do the same.

No doubt Wikidata and Commons are two projects where people are typically somewhat active on besides their home project. But that is the reason I excluded the data in my analysis below. Otherwise, a user who is highly active in 3 Wikipedias and a user who is highly active in 1 Wikipedia + Commons + Wikidata would appear similar. I am open to a different analytical approach too. Perhaps I should do the analysis by separating out and grouping together all wikis with local IPBE from all others; after all, one could argue for wikis with local IPBE the best approach is to drive the users towards that process, and reserve GIPBE for other wikis. Huji (talk) 00:39, 18 February 2026 (UTC)[reply]

As a follow up, I did some analysis. Turns out more than half of users with GIPBE are only really active in a single wiki (defined as having more than 500 edits on the wiki, excluding commons and wikidata), and another 20% of them are really only active on 2 wikis (with enwiki being a common second wiki for them). Most of these are zhwiki users. In other words, in more than half the cases, Stewards are granting GIPBE to users who are primarily and almost exclusively active on a single wiki that typically has its own internal IPBE. Why not let those communities grant local IPBE instead? Please be sure to check the graphs at the bottom of my analysis. Huji (talk) 00:57, 17 February 2026 (UTC)[reply]

@Huji: Your Jupyter notebooks are not visible to others (or at least not to me). NguoiDungKhongDinhDanh 00:59, 17 February 2026 (UTC)[reply]

@NguoiDungKhongDinhDanh: public link. – DreamRimmer ■ 01:07, 17 February 2026 (UTC)[reply]

Oppose, reason being that this is a tool that stewards use to balance their own blocks - so they shouldn't be prevented from allowing a bypass of their own blocks. If a local project wants to block something, they can do it themselves. — xaosflux ^Talk 01:33, 18 February 2026 (UTC)[reply]
Strong oppose: On what grounds?? First of all, the fact that we GIPBEers are granted this privilege already shows that we are cross-wiki active users with no obvious misconduct. When we edit on fawiki, we are commonly there to counter vandalism — so why add another barrier that interferes with cross-wiki active users like us? Secondly, since we have GIPBE, we are legally allowed to use proxies to edit all sites, and in fact we need to use them. So why impose an additional obstacle on us? A simple local block would suffice. Why should GIPBE be rendered completely ineffective on a particular site? If this wikiset is established and a bunch of sites are added, then what use is GIPBE to us anymore? I feel that instead of making this proposal, it would be better to propose abolishing the GIPBE user group altogether. 浅村しき (talk) 15:36, 4 March 2026 (UTC)[reply]
Support None of the people here should have the right to second-guess the way fawiki wants to structure its user rights, even if you think that they are silly and misguided. * Pppery * _{it has begun} 04:59, 6 March 2026 (UTC)[reply]
What? No part of this has anything to do with local user rights. That local project is welcome to manage all of their users, their local rights, and their blocks. No part of this has anything to do with overriding local governance. — xaosflux ^Talk 13:46, 6 March 2026 (UTC)[reply]
On the contrary, the decision "only local admins can decide who is allowed to edit through proxies" is precisely a local governance decision that, as I see it, you are unfairly vetoing. * Pppery * _{it has begun} 17:04, 6 March 2026 (UTC)[reply]
Local projects may block all the proxies, or any other IP or IP range they would like to, and once they do they have direct control of who may bypass their blocks. Additionally, local projects have the ability to override or bypass external blocks that affect their project, either entirely or for their users or usergroups. — xaosflux ^Talk 19:19, 6 March 2026 (UTC)[reply]
Oppose per xaosflux's stated reasoning. Codename Noreste (talk • contribs) 19:14, 6 March 2026 (UTC)[reply]
Oppose Xaosflux is right here. Local wikis wanting more control over proxy blocks are welcome to simply adopt all proxy blocks locally. Nothing is stopping them from locally blocking every identified proxy, so if it's such a big deal for fawiki, surely some local admins would be more than happy to do so. EggRoll97 (talk) 05:59, 7 March 2026 (UTC)[reply]

I close this request per discussion.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 (WikiBayerCatHelper) 18:55, 8 March 2026 (UTC)[reply]

Going back to in process as status. Such requests should only be closed by stewards. As Amanda said above, we (stewards) will discuss this. I understand, that the discussion here seems to have some consensus, however, determaining consensus is up to the stewards. Furthermore, you've commented on this already and shouldn't close requests you are involved with. -Barras talk 19:33, 8 March 2026 (UTC)[reply]

XML import on Meta

Status: In progress

Please import the following pages to Meta with full history (convenient link to Special:Export):

There are 676 revisions in all, only two of which (188443, 188444) aren't mine but fandom:dev:User:Kirkburn's, who seems to be the same as en:User:Kirkburn. These two edits are trivial so copyright is probably not a concern. NguoiDungKhongDinhDanh 04:06, 6 March 2026 (UTC)[reply]

If copyright isn't a concern just for this in, link to your original - no reason we need to host all these revisions here. — xaosflux ^Talk 11:01, 6 March 2026 (UTC)[reply]

I need to preserve those for development convenience. NguoiDungKhongDinhDanh 13:16, 6 March 2026 (UTC)[reply]

OAuth permissions

Preferably permission requests should be submitted using the form from Special:OAuthConsumerRegistration.

After submitting this form, you will receive a token that your application will use to identify itself to MediaWiki. An OAuth administrator will need to approve your application before it can be authorized by other users. It is possible to request approval using {{oauthapprequest}}; please create a sub-section of this section.

A few recommendations and remarks:

Try to use as few grants as possible. Avoid grants that are not actually needed now.
Versions are of the form "major.minor.release" (the last two being optional) and increase as grant changes are needed.
Please provide a public RSA key (in PEM format) if possible; otherwise a (less secure) secret token will have to be used.
Use the JSON restrictions field to limit access of this consumer to IP addresses in those CIDR ranges.
You can use a project ID to restrict the consumer to a single project on this site (use "*" for all projects).
The email address provided must match that of your account (which must have been confirmed).

Script Publisher - OAuth Toolforge tool for publishing public Git repositories to Wikimedia JS/CSS pages

Hello Stewards and community,

I am requesting community and steward review for an OAuth-based Toolforge application called Script Publisher, which allows Wikimedia contributors to publish JavaScript and CSS files from a public Git repository (for example GitHub) to Wikimedia wiki pages such as user scripts and gadgets via a web interface.

This tool is an implementation of the Community Wishlist Survey 2022 proposal:

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Bots_and_gadgets/A_bot_or_gadget_to_publish_public_Git_repo_to_a_gadget_or_user_script

The original proposer of this wishlist item is User:Nux, who has reviewed the prototype and provided detailed technical and UX feedback.

Project background

The project started with a working web prototype (Node/Next.js): https://wikipublisher.vercel.app/

This prototype was shared with the proposer (Nux), who confirmed it matches the intent of the wishlist and suggested several improvements including OAuth, Toolforge hosting, multi-target publishing, profiles, and safeguards. Based on that feedback and mentoring from the Developer Skill Development Program India 2025 (mentor: User:KCVelaga), the project is now being migrated to a production-ready Toolforge stack using Python + Django.

Toolforge deployment: https://script-publisher.toolforge.org/

Source code (Toolforge repository): https://gitlab.wikimedia.org/toolforge-repos/script-publisher/

What the tool does

Script Publisher provides a web interface that allows a user to:

Provide a public Git repository
Browse and select JavaScript and CSS files
Map each file to one or more target wiki pages (user scripts, gadgets, etc.)
Preview the exact content and destinations before publishing
Trigger a manual publish action

The tool does not perform automatic or background deployments. Every deployment requires explicit user confirmation and shows exactly what will be edited.

OAuth and security model

The application uses Wikimedia OAuth for authentication. OAuth is only used to act as the authenticated user — the tool can only perform edits that the user already has permission to perform manually.

If a user can edit a JavaScript or CSS page manually, they can deploy it via the tool. If they cannot, the tool also cannot.

An OAuth client was registered for this project: https://meta.wikimedia.org/wiki/Special:OAuthListConsumers/view/e51b6e0aa6bc2a5c60a315102e88d2ee

During OAuth review, WMF security (Tgr) noted that OAuth tools which can edit JavaScript should go through a community review process comparable to bots or global interface editors. This discussion can be found here: https://meta.wikimedia.org/wiki/User_talk:Dev_Jadiya?markasread=5796209&markasreadwiki=metawiki#c-Tgr_(WMF)-20260105205500-KCVelaga-20260103085000

This request is being made following that guidance.

Why this requires global permission

Script Publisher is designed to deploy JavaScript and CSS across Wikimedia projects. Functionally, this is equivalent to tools used by Global Interface Editors or JS deployment bots, and therefore requires the same level of community and steward oversight.

The tool is hosted on Toolforge with public source code, controlled deployment, and limited developer access, so that any changes to the tool itself are auditable and reviewed.

What is being requested

I am requesting approval for Script Publisher to operate as a Toolforge OAuth application with permissions equivalent to Global Interface Editors, so that it can publish JS/CSS pages on behalf of users who already have the rights to edit those pages.

The tool will not bypass MediaWiki permission checks and will not perform unattended or hidden edits.

Thank you for reviewing this request.

Dev Jadiya (talk) 18:59, 14 January 2026 (UTC)[reply]

Discussion

The wikitech documentation at wikitech:OAuth#Security explicitly calls out that this will not be permitted. Has a full tech discussion of this prohibition already occurred elsewhere? — xaosflux ^Talk 19:46, 14 January 2026 (UTC)[reply]

Thank you for pointing that out.

Yes - this discussion around the OAuth security concerns and the prohibition you referenced is already ongoing here:

https://meta.wikimedia.org/wiki/User_talk:Dev_Jadiya#Script_Publisher

This thread includes comments from User:Tgr (WMF) and User:KCVelaga about the risk model, why community review is being pursued, and how the tool will explicitly require user confirmation for edits.

Thank you. Dev Jadiya (talk) 14:10, 16 January 2026 (UTC)[reply]