Forwarding some job listings, including selected quotes from the listings.
1. *https://www.demogr.mpg.de/en/career_6122/jobs_fellowships_1910/post_doctoral_researcher_15072
<https://www.demogr.mpg.de/en/career_6122/jobs_fellowships_1910/post_doctora…>*
- applications due 8 April. "The Max Planck Institute for Demographic
Research (MPIDR) is seeking to appoint a full-time post-doctoral researcher
to join the Research Group on Labor Demography." "We welcome applications
from researchers with a PhD in demography, statistics, sociology,
economics, epidemiology, public health, or allied fields." "Strong
quantitative analysis skills are required, as is knowledge of R, Stata, or
Python."
2. *https://www.demogr.mpg.de/en/career_6122/jobs_fellowships_1910/max_planck_postdoc_positions_on_artefacts_for_the_social_sciences_15266
<https://www.demogr.mpg.de/en/career_6122/jobs_fellowships_1910/max_planck_p…>*
-
applications due 13 April. "The Max Planck Institute for Software Systems
(Kaiserslautern and Saarbruecken), the Max Planck Institute for Security
and Privacy (Bochum), The Max Planck Institute for Demographic Research
(Rostock), and the Max Planck Institute for the Study of Crime, Security
and Law (Freiburg) are jointly recruiting up to 8 highly qualified
Post-Docs interested in Computational Social Science. This application call
is targeted to the broad topic of artificial intelligence, computing, and
society."
3. *https://www.demogr.mpg.de/en/career_6122/jobs_fellowships_1910/doctoral_student_position_15039
<https://www.demogr.mpg.de/en/career_6122/jobs_fellowships_1910/doctoral_stu…>*
-
applications due 15 April. "The Max Planck Institute for Demographic
Research (MPIDR) is inviting applications from qualified and highly
motivated students for a doctoral student position in the Lab of Migration
and Mobility of the Department of Digital and Computational Demography."
"The Lab of Migration and Mobility of the Department of Digital and
Computational Demography, headed by MPIDR Director Emilio Zagheni, is
looking for candidates with strong quantitative and programming skills, and
with research interests in the fields of demography, migration studies,
science of science, and computational social science."
Pine🌲
Hello,
The Data Platform SRE team needs to carry out an upgrade of our
*dse-k8s-eqiad* Kubernetes cluster, which will require some downtime for
services hosted on this cluster.
If you don't use any of these services, you can ignore the rest of this
message.
* Airflow
* DataHub
* GrowthBook
* Flink
* Spark History
* Superset
* Test Kitchen
These services will, unfortunately, require downtime while the
Kubernetes upgrade is in progress.
The maintenance window, during which we will carry out the upgrade is
this *Thursday March 26th, between 10:30 and 15:00 UTC*.
Some of our dse-k8s workload is already available in a multi-dc capacity
on the *dse-k8s-codfw* cluster, so will *not* require downtime.
Specifically, these are our OpenSearch on Kubernetes clusters for:
* opensearch-ipoid
* opensearch-semantic-search
We will be keeping this ticket updated throughout the maintenance
window, on our progress:
T414484 Upgrade DSE clusters to kubernetes 1.31
<https://phabricator.wikimedia.org/T414484>
Once the Airflow services are running again, we will be working with
representatives from the Data Engineering team to ensure that all data
pipeline tasks have been addressed.
If you have any queries, comments, or concerns, please don't hesitate to
share them with us.
You can get in touch with us by reply to this message, or via
#data-platform-sre on Slack, or #wikimedia-data-platform on IRC.
Kind regards,
Ben
--
*Ben Tullis*(he/him)
Staff Site Reliability Engineer
Wikimedia Foundation <https://wikimediafoundation.org/>
Has the format of the data lake history files changed? Some code I have which works with these assumes 70 fields, and that jives with what's documented at https://wikitech.wikimedia.org/wiki/Data_Platform/Data_Lake/Edits/MediaWiki…. But it looks like there's now 76 fields:
$ bzcat 2026-01.enwiki.2026-01.tsv.bz2 | head -1 | tr '\t' '\n' | wc -l
76
Hello,
We have to carry out some maintenance of our Druid
<https://wikitech.wikimedia.org/wiki/Data_Platform/Systems/Druid> public
cluster, which will unfortunately require a period of service downtime.
The work is scheduled for next Monday, March 16th at approximately 10:30
UTC and is expected to take between 30 and 60 minutes.
Systems adversely affected will be:
* Superset - when querying the Druid Public (AQS) database
* Analytics Query Services (AQS) APIs:
o
Edit Analytics
o
Editor Analytics
* Global Editor Metrics
o Mobile Apps activity tab
o Growth Team impact module
o Year in review
We will be upgrading the Druid cluster during this time, as well the
operating systems of the hosts that serve the cluster.
Sadly, we are unable to carry out a rolling upgrade of the Druid
cluster, so this downtime is unavoidable.
If you have any particular concerns or queries about this maintenance
window, then please get in touch and we can look into deferring or
rescheduling this work.
Kind regards,
Ben
--
*Ben Tullis*(he/him)
Staff Site Reliability Engineer
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi, I'm forwarding the below to additional email lists in case the
announcement interests additional people who aren't subscribed to
Wiktech-l. I suggest that any questions or comments for this topic which
are intended for public email discussion be placed in the original thread
on Wikitech-l
Regards,
Pine🌲
---------- Forwarded message ---------
From: Jonathan Tweed via Wikitech-l <wikitech-l(a)lists.wikimedia.org>
Date: Mon, Mar 2, 2026 at 8:44 AM
Subject: [Wikitech-l] New global API rate limits
To: <wikitech-l(a)lists.wikimedia.org>
Cc: Jonathan Tweed <jtweed(a)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…>,
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…>
.
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-Agen…>
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(a)wikimedia.org
Best
Jonathan
--
*Jonathan Tweed* (he/him)
Senior Product Manager, Core Platform
Wikimedia Foundation <https://wikimediafoundation.org/>
_______________________________________________
Wikitech-l mailing list -- wikitech-l(a)lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave(a)lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/