Jump to content

Steward requests/Global permissions

Add links
From Meta, a Wikimedia project coordination wiki
< Steward requests
(Redirected from SRGRN)
Shortcut:
SRGP
This page hosts requests for global permissions. To make a request, read the relevant policy (global rollback , global sysop , global rename , …) and make a request below. Explain why membership is needed for that group, and detail prior experience or qualifications.

This is not a vote and any active Wikimedia editor may participate in the discussion.

Global rollback and global interface editor requests require no fewer than 5 days of discussion while abuse filter helper and maintainer requests require no fewer than 7 days. Global renamer and global sysop requests require no fewer than 2 weeks of discussion. For requests that are unlikely to pass under any circumstances, they may be closed by a steward without further discussion (after a reasonable amount of input).

Quick navigation:
Dynamic pages:

Cross-wiki requests
Meta-Wiki requests


Requests for global rollback permissions

[edit]

Requests for global sysop permissions

[edit]

Requests for global rename permissions

[edit]

Global rename for S.Marchenko

[edit]
The following request is closed. Please do not modify it. No further edits should be made to this discussion.
Status:    Withdrawn
Not ending before 19:00, 24 March 2026 (UTC)

Greetings, colleagues! I would like to obtain the status of Global Renamer.
A little about myself: I've been editing the Russian Wikipedia for a little over a year, and I also patrol it. I also frequently upload files to the Commons and translate texts into Russian on Meta-Wiki. Several reasons prompted me to make this request.
Reason 1: We only have three users with this permission on RuWiki. One of them isn't very active in our section, the second is an administrator and handles administrative work, and due to the admin shortage, this work is extensive and leaves no time for renaming. The third user is an active bureaucrat; yes, he primarily processes requests, but I intend to assist him with this, so he can devote more time to his bureaucratic work.
And reason 2: I have a strong desire to help my project and the Wikimedia Foundation as a whole. Please do not judge me harshly, I hope for your understanding. Sincerely yours, -- S.Marchenko (talk) 19:00, 10 March 2026 (UTC)[reply]

I'd also like to add that I've read the global renaming policy and the policy regarding global renamers. I'm only going to be working on this on RuWiki, but if you need help, I can help here too. Sincerely, S.Marchenko (talk) 19:36, 10 March 2026 (UTC)[reply]
Request withdrawn O, okey! Stewards, please close the request as per my request. It seems I won't receive support due to my recent involvement with the project. I'll gain some experience and try again in a couple of years. Thank you to everyone who commented; your opinion is important to me! Sincerely, Yours S.Marchenko (talk) 15:14, 11 March 2026 (UTC)[reply]

Requests for global IP block exemption

[edit]

Blevan7 (talk · contribs)

[edit]
  • Status:    Locally handled

I am requesting a Global IP Block Exemption. I am an editor on English Wikipedia. I am currently unable to log in to the Georgian Wikipedia (ka.wiki) because my ISP's IP range (2607:FB90::/32) is subject to a global block by Xaosflux. This is preventing the SUL (Single User Login) handshake, causing "cookie errors" and login failures on the Georgian project. Blevan7 (talk) 14:41, 16 March 2026 (UTC)[reply]

Done @Blevan7: I've attached your account to kawiki, please try again. — xaosflux Talk 14:43, 16 March 2026 (UTC)[reply]
Thank you very much, it works now. Blevan7 (talk) 14:53, 16 March 2026 (UTC)[reply]
For any other projects - note there is currently a wide block for not-logged-in users on T-MOBILE (the network range you listed above). If you have access to a non-T-MOBILE connection, logging in there will attach your account as expected. — xaosflux Talk 15:17, 16 March 2026 (UTC)[reply]
Got it. Thank you very much again. Blevan7 (talk) 19:05, 16 March 2026 (UTC)[reply]

Requests for other global permissions

[edit]

apihighlimits for GergesBot

[edit]
Status:    In progress

Hello, I would like to request the apihighlimits permission for WikiMonitor tool. The tool relies on Wikimedia SSE to access recent changes; however, I need to analyze certain edits, such as retrieving the text added to pages and similar data. Note: No page is analyzed unless there is an active user connected to the tool. (Technical note: The tool is currently in a pre-release stage. The source code will be published soon. You can try the tool at: https://wikimonitor.toolforge.org. The tool is developed in Java). Best regards--Gerges (Talk) 12:20, 8 February 2026 (UTC)[reply]

  • Support Support--Mohammed Qays (talk) 12:17, 9 February 2026 (UTC)[reply]
  • Strong support Strong support وسيم (talk) 21:53, 21 February 2026 (UTC)[reply]
  • Valid use case. I just tested this tool; it's a global anti-vandalism tool that can filter edits based on many raw filters available on the Wikimedia event stream. It's currently slow and faces limits when loading diffs, so having apihighlimits would be helpful. – DreamRimmer ■ 14:23, 9 February 2026 (UTC)[reply]
  • How would this work, as almost no users have this access. If it doesn't work without a global exemption, users aren't going to be able to make use of it. — xaosflux Talk 14:34, 9 February 2026 (UTC)[reply]
    Hi Xaosflux, I restricted access for users because the tool is only in the testing phase.-- Gerges (Talk) 14:58, 9 February 2026 (UTC)[reply]
    That's not what I'm asking. Almost no users have global apihighlimits access - if this tool requires that how would it ever get used? — xaosflux Talk 15:08, 9 February 2026 (UTC)[reply]
    @Xaosflux, My personal account is the account through which all API requests in the tool are processed, with the exception of rollback requests. Gerges (Talk) 15:11, 9 February 2026 (UTC)[reply]
    Hmm, I'm not sure if this is a good idea according to foundation:Policy:Wikimedia Foundation API Usage Guidelines , specifically that you want to funnel others who are not allowed to request at this rate. — xaosflux Talk 18:56, 9 February 2026 (UTC)[reply]
    Hi @Xaosflux, thank you for raising this concern. To clarify, the tool does not expose apihighlimits capabilities to end users, nor does it act as a proxy to bypass API limits on their behalf. All high-limit API requests are executed server-side under a single, accountable tool account, and only for internal processing (such as fetching diffs for analysis triggered by SSE events).
    Users do not directly control the request rate, cannot submit arbitrary API queries, and cannot exceed what the tool itself requires for its functionality. Additionally, the tool is rate-limited internally and only processes edits when there is at least one active user connected.
    The intent is to support a centralized anti-vandalism workflow, similar to other Toolforge tools that operate under a single service account.-- Gerges (Talk) 19:16, 9 February 2026 (UTC)[reply]
    Have you contacted the Data Platform Engineering team about your idea (or perhaps User:TChin (WMF))? — xaosflux Talk 19:28, 9 February 2026 (UTC)[reply]
    @Xaosflux, No.-- Gerges (Talk) 19:32, 9 February 2026 (UTC)[reply]
    @TChin (WMF): should the mw:Data Platform Engineering/Intake Process be used for this? — xaosflux Talk 19:34, 9 February 2026 (UTC)[reply]
    Hi friends! @TChin (WMF) is occupied and unable to respond right now, but I'm checking with folks about this. I think this is probably not a Data Platform Engineering ("DPE")-oriented topic, at least not with the current tech stack. But, I'll work to see if I can help make a connection in the right place.
    @Gerges are you able to share some screenshots or an animated GIF or video of the UI to showcase its facilities here a little more? If I understand correctly, the tool would respond to EventStreams by making additional requests against Action API or REST API endpoints to get relatively larger data payloads, possibly with higher velocity. Is that right? Thinking out loud, I'm wondering if there's some WMCS-accessible alternative for fetching the data via replica or some other WMCS-hosted route. But, hoping to learn a little more about the nature of the fetching behavior of the tool. Able to speak a bit to probable initial-to-medium-term request velocity and payload sizes, target data sources, and so forth? ABaso (WMF) (talk) 16:26, 10 February 2026 (UTC)[reply]
    @ABaso (WMF), I will publish the source code for the project today or tomorrow. Gerges (Talk) 16:30, 10 February 2026 (UTC)[reply]
    @ABaso (WMF) thanks for the note, my initial concern is that someone wanting to use a standard account as an API hook to relay to other users may not the the best route here. — xaosflux Talk 17:19, 10 February 2026 (UTC)[reply]
    Hi @Xaosflux, Should I create another account (for example, named GergesTools) so I can use it in the API? Gerges (Talk) 18:19, 10 February 2026 (UTC)[reply]
    Let's see if the DPE people have a better idea, like an application API key. — xaosflux Talk 18:24, 10 February 2026 (UTC)[reply]
  • Question Question: Specifically, which API modules does your appplication use where multi-value parameters are used extensively? Dragoniez (talk) 11:14, 10 February 2026 (UTC)[reply]
    Hi @Dragoniez, The application uses the MediaWiki Action API, mainly the compare and query modules.
    Multi-value parameters are primarily used in action=query, especially with list=users through parameters like usprop, which return multiple values such as rights and groups.
    Overall, the tool relies on API modules that natively support multi-value parameters, particularly action=query.-- Gerges (Talk) 13:14, 10 February 2026 (UTC)[reply]
  • @ABaso (WMF), This is the project repository: wiki-connect/wikimonitor.-- Gerges (Talk) 01:12, 11 February 2026 (UTC)[reply]
    Hi @Gerges and @Xaosflux, thanks for the continued dialogue here.
    Okay, I looked through the code. Here are some thoughts.
    I agree, it's best to get a separate bot account for reads on behalf of other users, rather than potentially duplicating API calls by multiple concurrent users. The coalescing of API calls is a reasonable pattern.
    If you batch up the usernames associated with the edits as conveyed by the stream and make an Action API call with a lot of them (say such as up to 5,000 distinct usernames), then you'd need the apihighlimit piece. If not that many usernames are added to filter watches this may not matter so much, it's just if you get a lot of usernames accumulated into early evaluation filter rules that have to run instead of short circuiting. If you won't be calling with so many usernames associated with edits at a time - let's say you only do up to 50 - the apihighlimit isn't really needed; this would equally apply if you decided to just page 50 lookups at a time even if it's more than 50. This reminds me: you may want to fetch both roles and groups at the same time if you're making this call, at least if you are pretty confident you'll need both.
    apihighlimit may not strictly be needed here for the action=compare call, as that has to be called sequentially one revision at a time instead of with a bunch of revision IDs (or, maximally, dispatched in parallel at a reasonable rate). apihighlimit is more oriented toward getting lots of records back at once. Eventually, however, the bot will probably need to be given the ability to make a higher velocity of requests because the raw velocity of diffs could be pretty nontrivial depending on the filters in play and how broadly applied they are across the various wikis. More information on the means of doing this will be on the way in the future for folks operating a trusted bot. If a filter is constrained to a low edit velocity wiki, this sequential calling is unlikely to be a big deal in the first place. Use of a mild level of parallelism for higher velocity wikis might mask the UX symptoms a little and help you get by, just be wary of lots of concurrent calls to action=compare dispatched through the Spring app in that case.
    Rather than needing to call action=compare over and over, it might be nice to use action=query&prop=revisions&rvdiffto=prev to get the diffs - meaning you could do 50 diffs at a time (or more if acquiring apihighlimit; although be careful - it's computationally expensive for the MediaWiki application servers to a degree). But rvdiffto=prev was deprecated in https://phabricator.wikimedia.org/T164106 , so although you can attempt to use that in the fashion of https://w.wiki/Hq7a , just be aware that it is deprecated, and also that it is not catered to handling Multi-Content Revisions. Usually you are probably looking for wikitext, so you may be fine with the implicit default "main" slot, but it's something to be mindful of in case of ever wanting to examine something other than that "main" slot, like other slotted data associated with a page (e.g., structured data on Commons).
    You could consider using action=query&prop=revisions without rvdiffto=prev (because it's deprecated) and doing diffing in your Spring application when both length.old and length.new are small so as to avoid very large collated payloads coming back; you'd need to mimic the HTML presentation one gets "for free" with rvdiffto=prev or action=compare in that case. There are some gotchas here. In every case some server component has to get the wikitext and some component has to perform the diff; there are certain caching mechanisms in the deeper backend, but there are also some tradeoffs. The benefit of action=compare is less data going between the MediaWiki application servers and your Spring app, which is good for the Spring app's performance in a way (upside it shifts the load to MediaWiki application servers; downside: it shifts some load to MediaWiki applications servers :) ) and better for the networking infrastructure in some sense - it's closer to a stream processing oriented way of doing things (and less like larger batching; although there are many forms of enqueuing things in stream based applications) which has some architectural benefits even if the payload serialization isn't optimized and the effect on the network is a little more chattiness. The benefit of prop=revisions (with deprecated rvdiffto=prev or with a heuristic on old and new size of the wikitext to avoid big calls) is fewer network calls altogether. A fancy way might be to consider processing action=compare on one queue where it's needed (e.g., where either of length.old or length.new is bigger) and using action=query&prop=revisions on another queue opportunistically; but it's more complicated. Maybe you find out that you can get away with a careful flow of action=compare if you're lucky, though.
    Undo, rollback, etc. should of course be done under the identity of an actual human (via their OAuth dance) who is initiating that behavior in the UI, and not under the identity of the bot. I think that's the intent here, but wanted to confirm understanding.
    Oh, you may be considering this (I didn't look closely), but you could grab user rights/roles (and more) along with revision info at the same time if you wanted to, like in https://w.wiki/Hq86 . But again, this hinges on whether you choose to use action=query&prop=revisions (with or without deprecated rvdiffto=prev ; formally you shouldn't use deprecated parameters, and you may thank yourself later if you don't! but I'm sure you'll consider your options; you should be mindful to watch for hard deprecation or performance bottlenecks if you do use it).
    I have some other code/config feedback if you'd be interested to discuss further. I could do Meet, Signal, or WhatsApp, if you like. If so, feel free to hit me up on IRC with your preferred contact channel and details and mutually available datetime slots next week and I could look and see if anything works. No obligation, of course. Also happy to email if you're interested in that at all, instead - please just side channel with the preferred email address and I can send it over instead of the video/audio call. I'm in Central Time US for correlation of clocks. ABaso (WMF) (talk) 23:06, 12 February 2026 (UTC)[reply]
    Hi @ABaso (WMF),
    Thank you very much for the detailed feedback and for taking the time to review the code. I truly appreciate your thoughtful analysis and the architectural considerations you shared — they are very helpful.
    @Xaosflux, Regarding the bot account, I already have a dedicated account named GergesBot, which can be granted the permissions apihighlimit.
    I would be glad to discuss the additional code and configuration feedback. You can reach me directly via WhatsApp or Telegram, whichever you prefer. Please feel free to contact me there and we can continue the discussion.
    Thank you again for your support and collaboration. Best regards-- Gerges (Talk) 23:32, 12 February 2026 (UTC)[reply]
    Hi @Gerges happy to help! Would you please email me with the preferred contact info for WhatsApp in this case? My email shows on my user page. ABaso (WMF) (talk) 10:53, 13 February 2026 (UTC)[reply]
    From above it seems like that is only something that should 'eventually' be needed, and shouldn't be stopping you from starting? — xaosflux Talk 00:49, 13 February 2026 (UTC)[reply]
    Hi @Xaosflux, I have completed all the notes provided to me by @ABaso (WMF) and sent him a file summarizing the changes.
    Currently, I have developed the tool so that it does not exceed the api limits. However, I would like to add some features that will require exceeding the API limit. Therefore, could you please grant the permissions apihighlimit to my account, GergesBot. Best regards-- Gerges (Talk) 21:30, 17 February 2026 (UTC)[reply]
    @Gerges for your development, which project(s) will you need these high access rates on? — xaosflux Talk 10:55, 18 February 2026 (UTC)[reply]
    @Xaosflux, Currently only the wikimonitor tool.-- Gerges (Talk) 10:58, 18 February 2026 (UTC)[reply]
    No, not what client, which of our projects for example 'arwiki'. — xaosflux Talk 11:01, 18 February 2026 (UTC)[reply]
    @Xaosflux, All projects.-- Gerges (Talk) 11:07, 18 February 2026 (UTC)[reply]
    I think this is excessive for something in development right now, however will leave this request open in case a different steward agrees. — xaosflux Talk 13:46, 18 February 2026 (UTC)[reply]
    @Xaosflux, Request the permissions before adding features that exceed the API limits, to prevent the tool from breaking.-- Gerges (Talk) 15:10, 18 February 2026 (UTC)[reply]
    @Xaosflux: I am not sure what potential issue you are seeing with granting the right to Gerges's bot account, as there appears to be a valid use case. Your initial concern about using a standard account as an API hook to relay data to other users is also addressed, since Gerges is willing to use a dedicated bot account instead. There is already precedent for this approach, as WikiBayer holds the right and their account makes API requests to fetch data for several tools, so Gerges would not be the only one allowing others to rely on API requests in this way. This is generally how things work when apihighlimits is required, as not every user has this right and using a single account to make such requests is often the only practical option. @Gerges: I will also note that similar tools like SWViewer do not appear to use an account with apihighlimits and still work without issues, although its maintainer previously had global sysop rights, which may have played a role on GS wikis, but that maintainer has since been removed from the GS group due to inactivity. I have not looked at the code for that tool, so I am not sure whether it was proxying API requests for others or relying on logged-in user accounts to make API requests. – DreamRimmer ■ 16:01, 18 February 2026 (UTC)[reply]
    I think this is premature, but am not hard-declining this request, just leaving it to any of the other stewards who may feel otherwise. — xaosflux Talk 16:07, 18 February 2026 (UTC)[reply]

See also

[edit]

Cooperation requests for: comments (local) (global) · translation

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Steward_requests/Global_permissions&oldid=30270511#Requests_for_global_rename_permissions"