Hi all
To help ensure fair and sustainable access https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Content_Reuse to Wikimedia resources, over the next month the Wikimedia Foundation will implement global API rate limits across our APIs.
Why we’re doing this
As we’ve shared over the last year https://diff.wikimedia.org/2025/04/01/how-crawlers-impact-the-operations-of-the-wikimedia-projects/, since 2024 we’ve observed a significant rise in automated requests, across scraping, APIs and bulk downloads. This is continuing to cause unsustainable load on our infrastructure, taking time and resources away that we need to support the Wikimedia projects, contributors and readers.
To ensure we can continue to provide preferential access for human and mission-oriented traffic, we need to reduce the amount of unidentified requests to our APIs from its current level of around 33%. This reduction will also enable us to improve governance around fair use, in line with our API Usage Guidelines https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_API_Usage_Guidelines .
What we’re doing
In early March, we will apply low limits to anonymous API requests that originate from outside Toolforge/WMCS and requests that are made from web browsers. In early April, higher limits will be applied to identified traffic, including authenticated requests.
Authenticated requests from a user in the ‘bot’ user group on any wiki will not be subject to these new limits, nor will clients which are well known to the Wikimedia Foundation. API requests from Toolforge/WMCS will also be exempt from rate limits for now.
Regardless, all developers are encouraged to familiarise themselves with the new limits and associated best practices to ensure they are not misclassified as abusive traffic. You can find this information at Wikimedia APIs/Rate limits https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits .
What this means in practice
Tools that use Wikimedia-hosted APIs, including Gadgets that make API requests, may be subject to new cross-API limits that are global across all Wikimedia projects. These limits are intentionally set as high as possible to minimise impact on the community.
We are asking developers to identify their requests to access higher limits. Tools running in Toolforge/WMCS are exempted for now, but we request that you follow the User-Agent policy https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_User-Agent_Policy and provide a meaningful User-Agent to help us correctly identify the source of traffic.
Otherwise, authenticating using session cookies or OAuth 2.0 will grant a higher limit. Where the authenticated user has the community approved bot right on any wiki, this will also exempt you from limits, even when the tool is not running on Toolforge/WMCS.
This request for authentication is a change from the previous guidance in the Robot policy, which suggested not authenticating to improve cache hit rates. We do not expect any significant impact from this change with current usage patterns and will be working over the next year to improve caching for authenticated requests.
Community impact
A key principle throughout this work has been to ensure responsible use of our infrastructure, whilst minimizing the impact on the community. Our communities rely on a broad ecosystem of bots and other tools to create and maintain the wikis, created by a dedicated group of technical volunteers.
These limits are being put in place to protect our projects from high levels of abuse and ensure that we are able to better insulate our community infrastructure from high-volume commercial usage. They are necessary to ensure that developers are using the most appropriate channels, giving us the ability to prioritize the community and our human readers.
Ideally, members of Wikimedia communities will not be affected by this change. However, it is possible that a small number of bots and other tools which operate at a very high rate may get rate limited. We ask you to follow the best practices and are here to help bot operators get the access they need.
What we need you to do
If you are a developer that uses Wikimedia APIs, we ask you to:
-
Read more about the new limits https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits and the updated Robot policy https://wikitech.wikimedia.org/wiki/Robot_policy -
Update your tools/bots to follow the new best practices
Should you require a higher rate of access, you are able to:
-
Request the bot flag https://www.mediawiki.org/wiki/Manual:Bots from your local wiki community -
Consider running in Toolforge or another WMCS offering -
Use Wikimedia Enterprise APIs https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access for high-volume usage
-
Contact the WMF at bot-traffic@wikimedia.org
Best
Jonathan
Why 2.0? All of my OAuth consumers use 1.0a. Will I need to generate new consumer keys?
On Mar 2, 2026, at 11:42 AM, Jonathan Tweed via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
Otherwise, authenticating using session cookies or OAuth 2.0 will grant a higher limit.
On Mon, 2 Mar 2026 at 16:52, Roy Smith roy@panix.com wrote:
Why 2.0? All of my OAuth consumers use 1.0a. Will I need to generate new consumer keys?
This is primarily because OAuth 2.0 uses access tokens that are formatted as JWTs, which we can validate extremely efficiently in services outside of MediaWiki. That means we can use authentication as a signal in abuse detection at the CDN without affecting performance, likewise using it to apply global API rate limits in an API gateway that sits in front of all MediaWiki instances.
If tools are running on WMCS, this will exempt you from the limits even when using OAuth 1.0.
For tools outside WMCS, OAuth 1.0 consumers will work as long as you also send cookies as this will include a JWT cookie in the request that we can validate in place of an OAuth 2.0 access token.
If neither of these are possible, then yes, it would make sense to generate new OAuth 2.0 clients.
Best Jonathan
On Monday, March 2nd, 2026 at 5:25 PM, Jonathan Tweed via Wikitech-lwikitech-l@lists.wikimedia.orgwrote:
If tools are running on WMCS, this will exempt you from the limits even when using OAuth 1.0.
For tools outside WMCS, OAuth 1.0 consumers will work as long as you also send cookies as this will include a JWT cookie in the request that we can validate in place of an OAuth 2.0 access token.
[Wikimedia APIs/Rate limits#Caveats](https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits#Caveats) says however that "OAuth 1 access tokens are not supported by the rate limit infrastructure. Requests using OAuth 1 tokens will be treated as unauthenticated with respect to rate limiting." Which is what's going to happen?
On Mon, 2 Mar 2026 at 18:41, Tenshi H mimasoew@protonmail.com wrote:
On Monday, March 2nd, 2026 at 5:25 PM, Jonathan Tweed via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
If tools are running on WMCS, this will exempt you from the limits even when using OAuth 1.0.
For tools outside WMCS, OAuth 1.0 consumers will work as long as you also send cookies as this will include a JWT cookie in the request that we can validate in place of an OAuth 2.0 access token.
Wikimedia APIs/Rate limits#Caveats says however that "OAuth 1 access tokens are not supported by the rate limit infrastructure. Requests using OAuth 1 tokens will be treated as unauthenticated with respect to rate limiting." Which is what's going to happen?
They are not supported on their own, but we are about to deploy a change that will generate a JWT cookie when you use bot passwords or OAuth 1. If this cookie is then sent alongside the OAuth 1 token, the request will be treated as authenticated. These are T417833 and T415007 in Phabricator and will be deployed over the next couple of weeks.
You are right, that page isn't as clear as it could be. I will update, thanks!
To clarify are rate limits applying to all api requests or only ones that hit the backend (i.e. Do cached api responses served by varnish count?)
-- Brian
On Mon, Mar 2, 2026 at 12:25 PM Jonathan Tweed via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
On Mon, 2 Mar 2026 at 18:41, Tenshi H mimasoew@protonmail.com wrote:
On Monday, March 2nd, 2026 at 5:25 PM, Jonathan Tweed via Wikitech-l
wikitech-l@lists.wikimedia.org wrote:
If tools are running on WMCS, this will exempt you from the limits even when using OAuth 1.0.
For tools outside WMCS, OAuth 1.0 consumers will work as long as you also send cookies as this will include a JWT cookie in the request that we can validate in place of an OAuth 2.0 access token.
Wikimedia APIs/Rate limits#Caveats says however that "OAuth 1 access
tokens are not supported by the rate limit infrastructure. Requests using OAuth 1 tokens will be treated as unauthenticated with respect to rate limiting." Which is what's going to happen?
They are not supported on their own, but we are about to deploy a change that will generate a JWT cookie when you use bot passwords or OAuth 1. If this cookie is then sent alongside the OAuth 1 token, the request will be treated as authenticated. These are T417833 and T415007 in Phabricator and will be deployed over the next couple of weeks.
You are right, that page isn't as clear as it could be. I will update, thanks! _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Good spot ;-) Strictly speaking, they will only apply to requests that hit the backend. However, that's extremely difficult to predict and if you send authentication, that's also currently uncached as so subject to limits anyway.
We are hopefully going to work on caching for authenticated requests next FY, so we may be able to make this more consistent then.
On Mon, 2 Mar 2026 at 20:37, bawolff via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
To clarify are rate limits applying to all api requests or only ones that hit the backend (i.e. Do cached api responses served by varnish count?)
-- Brian
On Mon, Mar 2, 2026 at 12:25 PM Jonathan Tweed via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
On Mon, 2 Mar 2026 at 18:41, Tenshi H mimasoew@protonmail.com wrote:
On Monday, March 2nd, 2026 at 5:25 PM, Jonathan Tweed via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
If tools are running on WMCS, this will exempt you from the limits even when using OAuth 1.0.
For tools outside WMCS, OAuth 1.0 consumers will work as long as you also send cookies as this will include a JWT cookie in the request that we can validate in place of an OAuth 2.0 access token.
Wikimedia APIs/Rate limits#Caveats says however that "OAuth 1 access tokens are not supported by the rate limit infrastructure. Requests using OAuth 1 tokens will be treated as unauthenticated with respect to rate limiting." Which is what's going to happen?
They are not supported on their own, but we are about to deploy a change that will generate a JWT cookie when you use bot passwords or OAuth 1. If this cookie is then sent alongside the OAuth 1 token, the request will be treated as authenticated. These are T417833 and T415007 in Phabricator and will be deployed over the next couple of weeks.
You are right, that page isn't as clear as it could be. I will update, thanks! _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Can we get exact numbers for these rate limits? "low", "medium", "high", and "very high" aren't very useful in the context of me trying to figure out if I should drop everything I am doing and allocate the next week to implementing OAuth 2.0 support for my bots and other hobby projects. One thing I will say about this change is that while I do completely understand that there is a need to cut down bot traffic to our servers, a change that involves rate-limiting contributor workflows, especially those who are performing (often) load-bearing moderation tasks, does not feel like a good way forward. Also, implementing OAuth 2.0 (and subsequently getting it approved) for support is non-trivial, especially for "home-grown" bots. Absent any evidence that community-run "home-grown" bots are the root of this problem, I feel like asking them to implement such a solution is counterproductive in this context. A few points wrt to some other parts of the announcement:
Otherwise, authenticating using session cookies or OAuth 2.0 will grant a
higher limit.
What about bot passwords (and OAuth 1.0a, as other folks have asked)? Note that adding OAuth 2.0 support is currently a significant burden compared to simply providing a proper UserAgent (which was the previous policy). I don't even know how I would implement OAuth 2.0 support for my Go bot (and random Python script) without spending a non-trivial amount of time reviewing the associated documentation.
Request the bot flag https://www.mediawiki.org/wiki/Manual:Bots from your
local wiki community
To my knowledge, this is also not a trivial process in many communities (e.g., enwiki). If I need to start a month-long (or more) discussion just to retrieve (say) the data for all recently reverted edits to perform my own analysis and/or make 1000 edits using Pywikibot, I feel like a contributor might ask/feel: "Will it be easier to just not do this task?"
Use Wikimedia Enterprise APIs
https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access for high-volume usage
This is the part I'm extremely uncomfortable with. I feel very strongly that community members who are contributing in mission-aligned ways should not be asked to shift to use a closed-source, monetary contributions-gated, out-of-date version of our own data that they have spent hours curating. I feel this is a very clear line in the sand: community members should NOT have to pay (i.e., buy/sign up for an Enterprise subscription) to access Wikimedia data. If we ever end up in a scenario where a contributor feels compelled to pay for a Wikimedia Enterprise account, we have done something seriously wrong. (The only caveat to that statement is if we have a contributor who founds an AI startup/Google alternative, or similar)
Regards, Sohom Datta --- Open-source contributor @Wikimedia
On Mon, Mar 2, 2026 at 12:25 PM Jonathan Tweed via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
On Mon, 2 Mar 2026 at 16:52, Roy Smith roy@panix.com wrote:
Why 2.0? All of my OAuth consumers use 1.0a. Will I need to generate
new consumer keys?
This is primarily because OAuth 2.0 uses access tokens that are formatted as JWTs, which we can validate extremely efficiently in services outside of MediaWiki. That means we can use authentication as a signal in abuse detection at the CDN without affecting performance, likewise using it to apply global API rate limits in an API gateway that sits in front of all MediaWiki instances.
If tools are running on WMCS, this will exempt you from the limits even when using OAuth 1.0.
For tools outside WMCS, OAuth 1.0 consumers will work as long as you also send cookies as this will include a JWT cookie in the request that we can validate in place of an OAuth 2.0 access token.
If neither of these are possible, then yes, it would make sense to generate new OAuth 2.0 clients.
Best Jonathan _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Hello Sohom, I'm Just jumping in here real quick on this specific section of your wider email. I cannot speak to the other questions you've asked so I will leave those to other people. But I wanted to just cover the separate, but specific points, that you mentioned about the *Enterprise *APIs as soon as possible:
...I feel very strongly that community members who are contributing in
mission-aligned ways should not be asked to shift to use a closed-source, monetary contributions-gated, out-of-date version of our own data that they have spent hours curating.
Although they are *primarily intended *for, and designed for the purposes of, high-volume commercial organisations, the API suite IS open source, like all WMF software. Also, it is not gated for only people who pay - accessible to *anyone *(including for commercial purposes) via its own website - at no cost. The payment comes with higher volume usage requirements and/or SLA contractual guarantees. Furthermore, there are alternative access methods *especially *for wikimedians, notably via WMCloudServicies. If none of that works for you there is also a published criteria method for requesting exceptional access to the higher speed/volume for - exactly as you mentioned - mission-aligned reasons. These access methods are documented here: https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access
If we ever end up in a scenario where a contributor feels compelled to pay
for a Wikimedia Enterprise account, we have done something seriously wrong.
I'll also link to the operating principles of the project here: https://meta.wikimedia.org/wiki/Wikimedia_Enterprise/Principles which, among things I've already mentioned, include a specific element which addresses, and guards against, that concern.
You can read the FAQ with sections about finance, tech, legal, and strategy/mission alignment here: https://meta.wikimedia.org/wiki/Wikimedia_Enterprise/FAQ If you have any further questions about that API suite - please come over to the talkpage on Meta wiki.
I do not wish to distract the mailing list from the larger points being made in the discussion on this thread - just to clarify these specific side issues. Sincerely,
*Liam Wyatt *(wittylama) [UTC 0/+1]
Senior Manager of Technology Partnerships
Wikimedia Foundation +44 7429 223 063 / lwyatt@wikimedia.org
Regards,
Sohom Datta
Open-source contributor @Wikimedia
On Mon, 2 Mar 2026 at 19:30, Sohom Datta via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
Can we get exact numbers for these rate limits? "low", "medium", "high", and "very high" aren't very useful in the context of me trying to figure out if I should drop everything I am doing and allocate the next week to implementing OAuth 2.0 support for my bots and other hobby projects. One thing I will say about this change is that while I do completely understand that there is a need to cut down bot traffic to our servers, a change that involves rate-limiting contributor workflows, especially those who are performing (often) load-bearing moderation tasks, does not feel like a good way forward. Also, implementing OAuth 2.0 (and subsequently getting it approved) for support is non-trivial, especially for "home-grown" bots. Absent any evidence that community-run "home-grown" bots are the root of this problem, I feel like asking them to implement such a solution is counterproductive in this context.
We are still finalizing the exact limits, but do intend to publish exact numbers as soon as we can. To give you an idea, anonymous requests will be in the hundreds per hour, authenticated several thousand per hour. To be clear, these limits will not apply to bots running on Toolforge/WMCS, regardless of whether they use authentication.
What about bot passwords (and OAuth 1.0a, as other folks have asked)? Note that adding OAuth 2.0 support is currently a significant burden compared to simply providing a proper UserAgent (which was the previous policy). I don't even know how I would implement OAuth 2.0 support for my Go bot (and random Python script) without spending a non-trivial amount of time reviewing the associated documentation.
Bot passwords and OAuth 1.0a will work if you send cookies, as this will send a JWT we can validate in the traffic layers before requests reach MediaWiki. Whilst this is non-standard for OAuth 1.0a, it’s the best compromise we were able to implement whilst we work together on a longer term transition towards OAuth 2.0 as the preferred method for API authentication. This will include improving the processes and documentation around OAuth 2.0, but is not something that we can wait for due to the pressures on our infrastructure from increased automated traffic.
Request the bot flag from your local wiki community
To my knowledge, this is also not a trivial process in many communities (e.g., enwiki). If I need to start a month-long (or more) discussion just to retrieve (say) the data for all recently reverted edits to perform my own analysis and/or make 1000 edits using Pywikibot, I feel like a contributor might ask/feel: "Will it be easier to just not do this task?"
This support was primarily intended as one way to ease the transition for existing tools. For most cases, the current exemption for WMCS and generous limits for authenticated traffic outside that environment should be sufficient for bots that wouldn’t otherwise need the bot flag. Operators of high-volume bots that may be impacted by this and need help finding a solution can also contact the WMF to discuss a potential exemption as a “known client”:
https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits#Get_help
Use Wikimedia Enterprise APIs for high-volume usage
This is the part I'm extremely uncomfortable with. I feel very strongly that community members who are contributing in mission-aligned ways should not be asked to shift to use a closed-source, monetary contributions-gated, out-of-date version of our own data that they have spent hours curating. I feel this is a very clear line in the sand: community members should NOT have to pay (i.e., buy/sign up for an Enterprise subscription) to access Wikimedia data. If we ever end up in a scenario where a contributor feels compelled to pay for a Wikimedia Enterprise account, we have done something seriously wrong. (The only caveat to that statement is if we have a contributor who founds an AI startup/Google alternative, or similar)
I know that Liam has just replied to this with further detail from an Enterprise perspective, but I want to address it directly too. We are absolutely not asking community members to shift to Enterprise, though they are able to request free access for mission-aligned purposes if they want to use one of the services it offers.
Indeed, these limits are being put in place in part to protect community access to existing community APIs. This pointer to Enterprise is primarily aimed at ensuring those that require what it offers in terms of commercial usage with SLAs etc are aware of it as an option that they should consider if they require high-volume access.
Thanks for the questions, I will start to collect these and other questions together in an FAQ on-wiki so that they are more broadly documented.
Il 02/03/26 22:41, Jonathan Tweed via Wikitech-l ha scritto:
To give you an idea, anonymous requests will be in the hundreds per hour, authenticated several thousand per hour.
That seems very easy to hit just doing some searches from the search bar. How are we going to detect the collateral damage on unregistered users?
Federico
FYI, this new limit seems to be affecting the InstantCommons https://www.mediawiki.org/wiki/InstantCommons feature used by many (if not most) external wikis. At appropedia.org we're experiencing many broken images, apparently because we've reached our request limit. This can actually be a good thing because it has forced me to upload to our server some images that were being used many times via templates and that shouldn't have been loaded from Commons in the first place. I just wanted to bring this up because it isn't currently documented at Wikimedia APIs/Rate limits https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits .
On Wed, Mar 4, 2026 at 10:23 AM Federico Leva (Nemo) via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
Il 02/03/26 22:41, Jonathan Tweed via Wikitech-l ha scritto:
To give you an idea, anonymous requests will be in the hundreds per hour, authenticated several thousand per hour.
That seems very easy to hit just doing some searches from the search bar. How are we going to detect the collateral damage on unregistered users?
Federico _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
On 2026-03-04 15:17, Felipe Schenone via Wikitech-l wrote:
FYI, this new limit seems to be affecting the InstantCommons <https:// www.mediawiki.org/wiki/InstantCommons> feature used by many (if not most) external wikis. At appropedia.org http://appropedia.org we're experiencing many broken images, apparently because we've reached our request limit. This can actually be a good thing because it has forced me to upload to our server some images that were being used many times via templates and that shouldn't have been loaded from Commons in the first place. I just wanted to bring this up because it isn't currently documented at Wikimedia APIs/Rate limits <https://www.mediawiki.org/ wiki/Wikimedia_APIs/Rate_limits>.
The API rate limits are not live yet, so the InstantCommons problems have to be caused by a different rate limiting change.
Perhaps it's due to the standardisation of thumbnail sizes: * https://phabricator.wikimedia.org/T414805 * https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/t...
Or perhaps due to whatever is causing this issue: * https://phabricator.wikimedia.org/T418323
Ironically, I was not able to debug on your website, as my attempt to preview an edit with a Commons image was blocked by an unsolvable Cloudflare CAPTCHA.
Its probably not this rate limit change (i assume its the media limit change), but many people have reported this with (quick) instant commons. I am aware of at least one site who was able to negotiate an exception to the limit.
QuickInstantCommons supports configuring the max cache time, as a first step try increasing that significantly.
-- Brian
On Wednesday, 4 March 2026, Bartosz Dziewoński via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
On 2026-03-04 15:17, Felipe Schenone via Wikitech-l wrote:
FYI, this new limit seems to be affecting the InstantCommons https:// www.mediawiki.org/wiki/InstantCommons feature used by many (if not most) external wikis. At appropedia.org http://appropedia.org we're experiencing many broken images, apparently because we've reached our request limit. This can actually be a good thing because it has forced me to upload to our server some images that were being used many times via templates and that shouldn't have been loaded from Commons in the first place. I just wanted to bring this up because it isn't currently documented at Wikimedia APIs/Rate limits https://www.mediawiki.org/ wiki/Wikimedia_APIs/Rate_limits.
The API rate limits are not live yet, so the InstantCommons problems have to be caused by a different rate limiting change.
Perhaps it's due to the standardisation of thumbnail sizes:
- https://phabricator.wikimedia.org/T414805
- https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists
.wikimedia.org/thread/LS2NVZTBZPQDK2W7IP66SHUXP2J54435/
Or perhaps due to whatever is causing this issue:
Ironically, I was not able to debug on your website, as my attempt to preview an edit with a Commons image was blocked by an unsolvable Cloudflare CAPTCHA.
-- Bartosz Dziewoński _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists .wikimedia.org/
On Wed, Mar 4, 2026 at 5:00 PM Brian Wolff via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
Its probably not this rate limit change (i assume its the media limit change), but many people have reported this with (quick) instant commons. I am aware of at least one site who was able to negotiate an exception to the limit.
QuickInstantCommons supports configuring the max cache time, as a first step try increasing that significantly.
To clarify this point a bit, given I see a lot of guesswork in this thread:
a) In the last year, we progressively started enforcing our user-agent policy, given that both QIC and IC allow you to set your own user-agent; if people modify their user-agent to include contact information, the limit is much higher than if they don't. In fact, not modifying the User-Agent is in violation of our user-agent policy. b) Both IC and QIC have the not-so-nice property of being O(N) in the number of API calls made, with N being the number of images imported; as Brian said, increasing the caching max time is an inevitable requirement if you are importing a lot of images c) It is still possible to get your bot identified; the blocking message includes an email address to contact to discuss exceptions d) Last I checked, both QIC and IC ship by default with configurations to use our CDN to serve thumbnails; given the progressive increase in bandwidth requirements, and the constant saturation of our internet links, we encourage people to host their own thumbnails if possible; especially if your site is very popular.
None of the above has anything to do with the announcement in this thread, but rather with the progressive enforcement of our robot policy over the last year.
Cheers,
Giuseppe
d) Last I checked, both QIC and IC ship by default with configurations to use our CDN to serve thumbnails; given the progressive increase in bandwidth requirements, and the constant saturation of our internet links, we encourage people to host their own thumbnails if possible; especially if your site is very popular.
This is a change in policy that has not been previously announced, is not documented on https://www.mediawiki.org/wiki/Manual:$wgUseInstantCommons, and does not match the default behavior of $wgUseInstantCommons. If WMF wants people to do something, they have to actually communicate it.
AntiCompositeNumber (they/them)
On Thu, Mar 5, 2026, at 01:30, Giuseppe Lavagetto via Wikitech-l wrote:
On Wed, Mar 4, 2026 at 5:00 PM Brian Wolff via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
Its probably not this rate limit change (i assume its the media limit change), but many people have reported this with (quick) instant commons. I am aware of at least one site who was able to negotiate an exception to the limit.
QuickInstantCommons supports configuring the max cache time, as a first step try increasing that significantly.
To clarify this point a bit, given I see a lot of guesswork in this thread:
a) In the last year, we progressively started enforcing our user-agent policy, given that both QIC and IC allow you to set your own user-agent; if people modify their user-agent to include contact information, the limit is much higher than if they don't. In fact, not modifying the User-Agent is in violation of our user-agent policy. b) Both IC and QIC have the not-so-nice property of being O(N) in the number of API calls made, with N being the number of images imported; as Brian said, increasing the caching max time is an inevitable requirement if you are importing a lot of images c) It is still possible to get your bot identified; the blocking message includes an email address to contact to discuss exceptions d) Last I checked, both QIC and IC ship by default with configurations to use our CDN to serve thumbnails; given the progressive increase in bandwidth requirements, and the constant saturation of our internet links, we encourage people to host their own thumbnails if possible; especially if your site is very popular.
None of the above has anything to do with the announcement in this thread, but rather with the progressive enforcement of our robot policy over the last year.
Cheers,
Giuseppe
Giuseppe Lavagetto Principal Site Reliability Engineer, Wikimedia Foundation _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Hi,
you are most likely hitting the limits that have been announced since last year in our robot policy, and very clearly stated there, which we started enforcing progressively and finally got applied fully in January.
What's most likely happening is that you haven't set proper contact information for you InstantCommons User-Agent, see https://www.mediawiki.org/wiki/InstantCommons#User-Agent_Policy
Cheers,
Giuseppe
On Wed, Mar 4, 2026 at 3:18 PM Felipe Schenone via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
FYI, this new limit seems to be affecting the InstantCommons https://www.mediawiki.org/wiki/InstantCommons feature used by many (if not most) external wikis. At appropedia.org we're experiencing many broken images, apparently because we've reached our request limit. This can actually be a good thing because it has forced me to upload to our server some images that were being used many times via templates and that shouldn't have been loaded from Commons in the first place. I just wanted to bring this up because it isn't currently documented at Wikimedia APIs/Rate limits https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits.
On Wed, Mar 4, 2026 at 10:23 AM Federico Leva (Nemo) via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
Il 02/03/26 22:41, Jonathan Tweed via Wikitech-l ha scritto:
To give you an idea, anonymous requests will be in the hundreds per hour, authenticated several thousand per hour.
That seems very easy to hit just doing some searches from the search bar. How are we going to detect the collateral damage on unregistered users?
Federico _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
On Wed, 4 Mar 2026 at 13:23, Federico Leva (Nemo) nemowiki@gmail.com wrote:
That seems very easy to hit just doing some searches from the search bar. How are we going to detect the collateral damage on unregistered users?
We are adding client side logging for rate limit errors in mw.API: https://phabricator.wikimedia.org/T418957
Browser limits in particular are still undergoing some iteration. We do intend to try and cover genuine use with what we put in place, but are going to directly monitor this to make sure.
Jonathan
I'm using the python-social-auth library. As far as I can tell, it only supports OAuth 1.
https://python-social-auth.readthedocs.io/en/latest/backends/mediawiki.html
On Mar 2, 2026, at 12:24 PM, Jonathan Tweed via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
On Mon, 2 Mar 2026 at 16:52, Roy Smith roy@panix.com wrote:
Why 2.0? All of my OAuth consumers use 1.0a. Will I need to generate new consumer keys?
This is primarily because OAuth 2.0 uses access tokens that are formatted as JWTs, which we can validate extremely efficiently in services outside of MediaWiki. That means we can use authentication as a signal in abuse detection at the CDN without affecting performance, likewise using it to apply global API rate limits in an API gateway that sits in front of all MediaWiki instances.
If tools are running on WMCS, this will exempt you from the limits even when using OAuth 1.0.
For tools outside WMCS, OAuth 1.0 consumers will work as long as you also send cookies as this will include a JWT cookie in the request that we can validate in place of an OAuth 2.0 access token.
If neither of these are possible, then yes, it would make sense to generate new OAuth 2.0 clients.
Best Jonathan _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
On Mon, 2 Mar 2026 at 21:42, Roy Smith roy@panix.com wrote:
I'm using the python-social-auth library. As far as I can tell, it only supports OAuth 1.
https://python-social-auth.readthedocs.io/en/latest/backends/mediawiki.html
That does look to be the case and I'm not sure that it implements cookie support directly. It may be possible to use requests.Session alongside this to implement the cookie support, as it uses requests_oauthlib.OAuth1 to handle the authentication.
More generally we are open to helping improve community libraries, either through code review or more active contribution.
The python-social-auth project welcomes contributions https://github.com/python-social-auth/.github/blob/main/CONTRIBUTING.md. If you could work with them to add OAuth2 support for the MediaWiki backend, that would be great.
On Mar 3, 2026, at 2:03 PM, Jonathan Tweed via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
On Mon, 2 Mar 2026 at 21:42, Roy Smith roy@panix.com wrote:
I'm using the python-social-auth library. As far as I can tell, it only supports OAuth 1.
https://python-social-auth.readthedocs.io/en/latest/backends/mediawiki.html
That does look to be the case and I'm not sure that it implements cookie support directly. It may be possible to use requests.Session alongside this to implement the cookie support, as it uses requests_oauthlib.OAuth1 to handle the authentication.
More generally we are open to helping improve community libraries, either through code review or more active contribution. _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Hi. Could you give a better approximation for the date for the browser limits applying? Because looks like https://meta.wikimedia.org/wiki/Talk:Wikimedia_APIs/Rate_limits#Rate_limits I need to rewrite a whole MediaWiki extension by then, and it will take time for me to write and debug, hopely about a week, and then enough time for reviewers to approve the change, and then waiting for the next deployment train. Thank you, Igal (User:IKhitron)
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Virus-free.www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
בתאריך יום ב׳, 2 במרץ 2026 ב-18:44 מאת Jonathan Tweed via Wikitech-l < wikitech-l@lists.wikimedia.org>:
Hi all
To help ensure fair and sustainable access https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Content_Reuse to Wikimedia resources, over the next month the Wikimedia Foundation will implement global API rate limits across our APIs.
Why we’re doing this
As we’ve shared over the last year https://diff.wikimedia.org/2025/04/01/how-crawlers-impact-the-operations-of-the-wikimedia-projects/, since 2024 we’ve observed a significant rise in automated requests, across scraping, APIs and bulk downloads. This is continuing to cause unsustainable load on our infrastructure, taking time and resources away that we need to support the Wikimedia projects, contributors and readers.
To ensure we can continue to provide preferential access for human and mission-oriented traffic, we need to reduce the amount of unidentified requests to our APIs from its current level of around 33%. This reduction will also enable us to improve governance around fair use, in line with our API Usage Guidelines https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_API_Usage_Guidelines .
What we’re doing
In early March, we will apply low limits to anonymous API requests that originate from outside Toolforge/WMCS and requests that are made from web browsers. In early April, higher limits will be applied to identified traffic, including authenticated requests.
Authenticated requests from a user in the ‘bot’ user group on any wiki will not be subject to these new limits, nor will clients which are well known to the Wikimedia Foundation. API requests from Toolforge/WMCS will also be exempt from rate limits for now.
Regardless, all developers are encouraged to familiarise themselves with the new limits and associated best practices to ensure they are not misclassified as abusive traffic. You can find this information at Wikimedia APIs/Rate limits https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits.
What this means in practice
Tools that use Wikimedia-hosted APIs, including Gadgets that make API requests, may be subject to new cross-API limits that are global across all Wikimedia projects. These limits are intentionally set as high as possible to minimise impact on the community.
We are asking developers to identify their requests to access higher limits. Tools running in Toolforge/WMCS are exempted for now, but we request that you follow the User-Agent policy https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_User-Agent_Policy and provide a meaningful User-Agent to help us correctly identify the source of traffic.
Otherwise, authenticating using session cookies or OAuth 2.0 will grant a higher limit. Where the authenticated user has the community approved bot right on any wiki, this will also exempt you from limits, even when the tool is not running on Toolforge/WMCS.
This request for authentication is a change from the previous guidance in the Robot policy, which suggested not authenticating to improve cache hit rates. We do not expect any significant impact from this change with current usage patterns and will be working over the next year to improve caching for authenticated requests.
Community impact
A key principle throughout this work has been to ensure responsible use of our infrastructure, whilst minimizing the impact on the community. Our communities rely on a broad ecosystem of bots and other tools to create and maintain the wikis, created by a dedicated group of technical volunteers.
These limits are being put in place to protect our projects from high levels of abuse and ensure that we are able to better insulate our community infrastructure from high-volume commercial usage. They are necessary to ensure that developers are using the most appropriate channels, giving us the ability to prioritize the community and our human readers.
Ideally, members of Wikimedia communities will not be affected by this change. However, it is possible that a small number of bots and other tools which operate at a very high rate may get rate limited. We ask you to follow the best practices and are here to help bot operators get the access they need.
What we need you to do
If you are a developer that uses Wikimedia APIs, we ask you to:
Read more about the new limits https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits and the updated Robot policy https://wikitech.wikimedia.org/wiki/Robot_policy
Update your tools/bots to follow the new best practices
Should you require a higher rate of access, you are able to:
Request the bot flag https://www.mediawiki.org/wiki/Manual:Bots from your local wiki community
Consider running in Toolforge or another WMCS offering
Use Wikimedia Enterprise APIs https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access for high-volume usage
Contact the WMF at bot-traffic@wikimedia.org
Best
Jonathan
-- *Jonathan Tweed* (he/him) Senior Product Manager, Core Platform Wikimedia Foundation https://wikimediafoundation.org/ _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Hi Igal. I am working closely with User:DKinzler (WMF) on this, who has been corresponding with you on-wiki.
We're thinking about how best to handle this and work with you on a solution. We can certainly help with priority reviews and potentially more actively if desired. Let's continue the conversation on the Talk page.
On Mon, 2 Mar 2026 at 19:48, יגאל חיטרון khitron@post.bgu.ac.il wrote:
Hi. Could you give a better approximation for the date for the browser limits applying? Because looks like https://meta.wikimedia.org/wiki/Talk:Wikimedia_APIs/Rate_limits#Rate_limits I need to rewrite a whole MediaWiki extension by then, and it will take time for me to write and debug, hopely about a week, and then enough time for reviewers to approve the change, and then waiting for the next deployment train. Thank you, Igal (User:IKhitron)
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Virus-free.www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#m_9012968100391432129_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
בתאריך יום ב׳, 2 במרץ 2026 ב-18:44 מאת Jonathan Tweed via Wikitech-l < wikitech-l@lists.wikimedia.org>:
Hi all
To help ensure fair and sustainable access https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Content_Reuse to Wikimedia resources, over the next month the Wikimedia Foundation will implement global API rate limits across our APIs.
Why we’re doing this
As we’ve shared over the last year https://diff.wikimedia.org/2025/04/01/how-crawlers-impact-the-operations-of-the-wikimedia-projects/, since 2024 we’ve observed a significant rise in automated requests, across scraping, APIs and bulk downloads. This is continuing to cause unsustainable load on our infrastructure, taking time and resources away that we need to support the Wikimedia projects, contributors and readers.
To ensure we can continue to provide preferential access for human and mission-oriented traffic, we need to reduce the amount of unidentified requests to our APIs from its current level of around 33%. This reduction will also enable us to improve governance around fair use, in line with our API Usage Guidelines https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_API_Usage_Guidelines .
What we’re doing
In early March, we will apply low limits to anonymous API requests that originate from outside Toolforge/WMCS and requests that are made from web browsers. In early April, higher limits will be applied to identified traffic, including authenticated requests.
Authenticated requests from a user in the ‘bot’ user group on any wiki will not be subject to these new limits, nor will clients which are well known to the Wikimedia Foundation. API requests from Toolforge/WMCS will also be exempt from rate limits for now.
Regardless, all developers are encouraged to familiarise themselves with the new limits and associated best practices to ensure they are not misclassified as abusive traffic. You can find this information at Wikimedia APIs/Rate limits https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits.
What this means in practice
Tools that use Wikimedia-hosted APIs, including Gadgets that make API requests, may be subject to new cross-API limits that are global across all Wikimedia projects. These limits are intentionally set as high as possible to minimise impact on the community.
We are asking developers to identify their requests to access higher limits. Tools running in Toolforge/WMCS are exempted for now, but we request that you follow the User-Agent policy https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Foundation_User-Agent_Policy and provide a meaningful User-Agent to help us correctly identify the source of traffic.
Otherwise, authenticating using session cookies or OAuth 2.0 will grant a higher limit. Where the authenticated user has the community approved bot right on any wiki, this will also exempt you from limits, even when the tool is not running on Toolforge/WMCS.
This request for authentication is a change from the previous guidance in the Robot policy, which suggested not authenticating to improve cache hit rates. We do not expect any significant impact from this change with current usage patterns and will be working over the next year to improve caching for authenticated requests.
Community impact
A key principle throughout this work has been to ensure responsible use of our infrastructure, whilst minimizing the impact on the community. Our communities rely on a broad ecosystem of bots and other tools to create and maintain the wikis, created by a dedicated group of technical volunteers.
These limits are being put in place to protect our projects from high levels of abuse and ensure that we are able to better insulate our community infrastructure from high-volume commercial usage. They are necessary to ensure that developers are using the most appropriate channels, giving us the ability to prioritize the community and our human readers.
Ideally, members of Wikimedia communities will not be affected by this change. However, it is possible that a small number of bots and other tools which operate at a very high rate may get rate limited. We ask you to follow the best practices and are here to help bot operators get the access they need.
What we need you to do
If you are a developer that uses Wikimedia APIs, we ask you to:
Read more about the new limits https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits and the updated Robot policy https://wikitech.wikimedia.org/wiki/Robot_policy
Update your tools/bots to follow the new best practices
Should you require a higher rate of access, you are able to:
Request the bot flag https://www.mediawiki.org/wiki/Manual:Bots from your local wiki community
Consider running in Toolforge or another WMCS offering
Use Wikimedia Enterprise APIs https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access for high-volume usage
Contact the WMF at bot-traffic@wikimedia.org
Best
Jonathan
-- *Jonathan Tweed* (he/him) Senior Product Manager, Core Platform Wikimedia Foundation https://wikimediafoundation.org/ _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Hi!
If I read this correctly, user scripts/gadgets such as this one https://meta.wikimedia.org/wiki/User:Dragoniez/MarkBLockedGlobal, which marks users that are globally blocked/locked, are also affected. This one (and others I am sure) can generate quite a lot of requests. None of the proposed solutions seem suitable to help with that. What can be done? Is proxying those requests through a toolforge webservice, which requires quite a bit of development effort, the only option?
Best regards,
Count Count
Hi,
thank you for bringing this up. We are currently working to adjust the limits in a way that will avoid disruption for outliers like this.
Can you give a rough estimate how much traffic that gadget would generate per usage? Hundreds of requests? Thousands?
Thanks, Daniel
Am 04.03.26 um 09:35 schrieb Count Count via Wikitech-l:
Hi!
If I read this correctly, user scripts/gadgets such as this one https://meta.wikimedia.org/wiki/User:Dragoniez/MarkBLockedGlobal, which marks users that are globally blocked/locked, are also affected. This one (and others I am sure) can generate quite a lot of requests. None of the proposed solutions seem suitable to help with that. What can be done? Is proxying those requests through a toolforge webservice, which requires quite a bit of development effort, the only option?
Best regards,
Count Count
Wikitech-l mailing list --wikitech-l@lists.wikimedia.org To unsubscribe send an email towikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
The MarkBLockedGlobal script currently does about 300 requests per page view of Steward Requests/Global on meta https://meta.wikimedia.org/wiki/Steward_requests/Global but it is also helpful on Special:Watchlist/Special:RecentChanges. I think 100-1000 requests is common, it can go over a 1000 in rare cases (though over 10000 would be unlikely). No idea what other request-heavy gadgets/user scripts exist.
Count Count
Am Mi., 4. März 2026 um 10:18 Uhr schrieb Daniel Kinzler < dkinzler@wikimedia.org>:
Hi,
thank you for bringing this up. We are currently working to adjust the limits in a way that will avoid disruption for outliers like this.
Can you give a rough estimate how much traffic that gadget would generate per usage? Hundreds of requests? Thousands?
Thanks, Daniel
Am 04.03.26 um 09:35 schrieb Count Count via Wikitech-l:
Hi!
If I read this correctly, user scripts/gadgets such as this one https://meta.wikimedia.org/wiki/User:Dragoniez/MarkBLockedGlobal, which marks users that are globally blocked/locked, are also affected. This one (and others I am sure) can generate quite a lot of requests. None of the proposed solutions seem suitable to help with that. What can be done? Is proxying those requests through a toolforge webservice, which requires quite a bit of development effort, the only option?
Best regards,
Count Count
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.orghttps://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
-- Daniel Kinzler Principal Software Engineer MediaWiki Engineering Group Wikimedia Foundation
A quick peek at ANI https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents shows over 1650 requests on a single load because I have the MarkLocked https://en.wikipedia.org/wiki/User:GeneralNotability/mark-locked.js script loaded on my account.
Regards, Sohom Datta --- Open-source contributor @Wikimedia, @Chromium
On Wed, Mar 4, 2026 at 4:41 AM Count Count via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
The MarkBLockedGlobal script currently does about 300 requests per page view of Steward Requests/Global on meta https://meta.wikimedia.org/wiki/Steward_requests/Global but it is also helpful on Special:Watchlist/Special:RecentChanges. I think 100-1000 requests is common, it can go over a 1000 in rare cases (though over 10000 would be unlikely). No idea what other request-heavy gadgets/user scripts exist.
Count Count
Am Mi., 4. März 2026 um 10:18 Uhr schrieb Daniel Kinzler < dkinzler@wikimedia.org>:
Hi,
thank you for bringing this up. We are currently working to adjust the limits in a way that will avoid disruption for outliers like this.
Can you give a rough estimate how much traffic that gadget would generate per usage? Hundreds of requests? Thousands?
Thanks, Daniel
Am 04.03.26 um 09:35 schrieb Count Count via Wikitech-l:
Hi!
If I read this correctly, user scripts/gadgets such as this one https://meta.wikimedia.org/wiki/User:Dragoniez/MarkBLockedGlobal, which marks users that are globally blocked/locked, are also affected. This one (and others I am sure) can generate quite a lot of requests. None of the proposed solutions seem suitable to help with that. What can be done? Is proxying those requests through a toolforge webservice, which requires quite a bit of development effort, the only option?
Best regards,
Count Count
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.orghttps://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
-- Daniel Kinzler Principal Software Engineer MediaWiki Engineering Group Wikimedia Foundation
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
wikitech-l@lists.wikimedia.org