Dear all,
On Wednesday March 19th 2025, the SRE team will run a planned datacentre
switchover <https://wikitech.wikimedia.org/wiki/Switch_Datacenter>, moving
all wikis from codfw to eqiad. This is an important periodic test of our
tools and procedures, to ensure the wikis will continue to be available
even in the event of major technical issues in our primary home. It also
gives all our SRE and ops teams a chance to do maintenance and upgrades on
systems in codfw that normally run 24 hours a day.
The switchover process requires a brief read-only period for all
Foundation-hosted wikis, which will start on Wednesday March 19th 2025 @
14:00 UTC <https://zonestamp.toolforge.org/1742392800>, and will last for
just a few minutes while we execute the migration as efficiently as
possible. All our public and private wikis will be continuously available
for reading, as usual, but editing will be unavailable during the process.
Users will see a notification of the upcoming maintenance, and anyone still
editing will be asked to try again in a few minutes.
If you like, you can follow along on the day in the public
#wikimedia-operations channel on IRC. To report any issues, you can reach
us in #wikimedia-sre on IRC, or file a Phabricator ticket with the
#datacenter-switchover tag (
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projects=Data…;
we'll be monitoring closely for reports of trouble during and after the
switchover. The switchover and its preparation will be tracked under
https://phabricator.wikimedia.org/T385155.
On behalf of the SRE team, please excuse the disruption, and we would like
to thank everyone in various departments who are involved in planning this
work. If you have any questions, please reply directly to this email, or
follow up on Phabricator or IRC.
Kind regards,
Hugh
Hello all!
The public WDQS Split Graph endpoints have been available for ~6 months, it
is time to have a look at what has been happening and at the next steps.
We don’t see a strong adoption of the new endpoints (~20 req/min for
query-scholary [1]). But we’ve identified almost 90% of the current
requests that would require migration to the split endpoints. The large
majority (~80%) are generated by a tool that is unfinished and has been
dropped by its author. Those queries are already broken or don’t have value
and will never be migrated. Unsurprisingly, Scholia is a major user of the
scholarly subgraph and has not migrated yet.
While we want to move forward, we also want to limit disruption, and give
more time to the projects that need it. To ease the transition, we’ve
created a new endpoint (query-legacy-full.wikidata.org) which contains the
full Wikidata graph, but is limited in terms of performances and
availability [2]. This new endpoint can be used in place of the current
query.wikidata.org for the few projects that need the additional migration
time. This endpoint will be available until December 2025.
The next big step is to drop support for the full Wikidata graph on
query.wikidata.org [3]. This should happen around April 10. After that
step, requests to query.wikidata.org that require the full graph will fail
or return invalid results if they are not rewritten to use SPARQL
federation [4]. You can ask for help to rewrite your queries [5].
In related news, Peter [6] has been exploring the performances of various
alternative RDF backends [7]. This is going to be invaluable when we work
on replacing Blazegraph!
Have fun!
Guillaume
[1]
https://grafana.wikimedia.org/d/000000489/wikidata-query-service?orgId=1&re…
[2] https://phabricator.wikimedia.org/T384422
[3] https://phabricator.wikimedia.org/T388134
[4]
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_graph_spli…
[5] https://www.wikidata.org/wiki/Wikidata:Request_a_query
[6] https://www.wikidata.org/wiki/User:Peter_F._Patel-Schneider
[7] https://www.wikidata.org/wiki/Wikidata:Scaling_Wikidata/Benchmarking
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
Deb - thanks for explaining what happened. We all make mistakes (except for
this Dennis guy, I suppose!), and it's at least good to know that Google
have not suddenly changed their minds about the Wikimedia Foundation.
However, perhaps something can be salvaged from this. There have been
various organization-specific mentorship programs that have been directly
inspired by the Google Summer of Code; here are some of them:
https://mentorship.kde.org/sok/https://www.x.org/wiki/XorgEVoC/https://www.summerofbitcoin.org/
What about having a "Wikimedia Summer of Code" or some such this summer? It
could more or less match what GSoC does, with the same timeframe(s), same
country-specific stipends, etc. Like these other org-specific programs, it
would piggyback on the GSoC concept, so that potential students will
already know what to expect.
Wikimedia has a big advantage over most other organizations that might wish
to do similar things, in that it already has a funding mechanism that could
be repurposed for this: the Rapid Grants program, whose $5,000 limit is
larger than all but the largest possible GSoC stipends. So in a sense,
nothing (as far as I know) would need to change officially: it would just
be a matter of putting up a wiki page telling potential mentors that they
need to apply via a Rapid Grant, as opposed to the GSoC website. (Of
course, it would be good for anyone handling the Rapid Grant applications
to know to expect a spate of technology-related ones!)
There have already been some great Wikimedia project ideas this year, and
(as with every year) there are students who are excited to specifically
work on Wikipedia- and Wikimedia-related projects. It would be a shame to
give up on these projects, and also potentially to lose momentum for
upcoming years, if the funding potential is there.
And yes, I'm aware of Outreachy, which as far as I know is still happening,
but it doesn't allow most of the people who would potentially be applying
for GSoC, so I don't see it as a real substitute. Others may, however.
Any thoughts?
-Yaron
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
Hello all!
The Search Platform Team usually holds an open meeting on the first
Wednesday of each month. Come talk to us about anything related to
Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query
Service (WCQS), etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, March 5, 2025
Time: 16:00-17:00 UTC / 08:00 PST / 11:00 EST / 17:00 CET
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vgj-bbeb-uyi
Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927
Have fun and see you soon!
Guillaume
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi all -
Unfortunately, the Wikimedia Foundation will not be participating in this
year's Google Summer of Code <https://summerofcode.withgoogle.com/>
program. We look forward to coming back in 2026. In the meanwhile, we will
be participating in Outreachy <https://www.outreachy.org/> round 30 this
summer. You can find out more in our call for projects
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…>.
Thank you for your patience and support.
- Developer Outreach team
--
Lani Goto (they/them)
Senior Technical Program Manager
Hi all!
This is a quick announcement that it’s now possible to make cross-origin
requests to the Action API authenticated using OAuth. This means you can
create tools / apps that use OAuth to act on the user’s behalf and that
run entirely in the browser, without needing a server-side component.
To make these requests, first obtain an OAuth 2 access token following
the usual authorization flow. (I think from MediaWiki’s point of view,
OAuth 1.0a would also be technically possible, but I think it would be
pretty difficult if not impossible to generate correct OAuth 1.0a
requests within the browser. Just use OAuth 2 :D) Addshore recently
published a blog post [1] going through the process in detail; you can
also use a library, such as yours truly’s m3api-oauth2 [2]. Then, when
you make a request against the Action API, include the crossorigin=
parameter in the request URL, and the API should allow the request and
respond with the needed CORS headers to make the browser return the
response to your JS code. (The parameter is boolean, so the value is
irrelevant and can be left empty. Note that, just as with the origin=
parameter, it must be part of the request URL and not the request body
of a POST request, so that it’s still included in a preflight request.)
A full example, with an included OAuth client, is available at [3].
Note that, if you’re building a fully client-side OAuth app, this
implies that you’ll be shipping the OAuth client (consumer) credentials
to your users, so you should mark the client as non-confidential when
requesting it (uncheck the “client is confidential” box on [4]).
Non-confidential clients are just as functional as confidential clients
(with the exception of T323855 [5] – to work around that, you can just
ship the client secret together with the client ID and treat both as
public); the “not confidential” flag mainly serves as a hint to the
OAuth administrators [6] that they shouldn’t revoke your client just
because its credentials were found “in the wild”, because it’s not
expected to be confidential in the first place. If you’d rather have
your OAuth credentials confidential after all, then you’ll instead need
to build your tool with a server-side component (such as a Toolforge
webservice) that can keep them secret.
This feature was only recently developed, so if you’re targeting
non-Wikimedia wikis, you’ll probably have to wait for the release of
MediaWiki 1.44 before you can start to use the new crossorigin=
parameter there. (It’s perhaps worth noting that the REST API has
supported OAuth-authenticated CORS for a while already, though it
doesn’t offer all of the same features as the Action API.)
For more information, see also [7], [8] and [9].
Cheers!
Lucas
[1]: https://addshore.com/2025/02/vuetify-app-with-wikimedia-oauth-login/
[2]: https://github.com/lucaswerkmeister/m3api-oauth2/
[3]:
https://github.com/lucaswerkmeister/m3api-examples/tree/main/webapp-clients…
[4]:
https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration/propose/o…
[5]: https://phabricator.wikimedia.org/T323855
[6]:
https://meta.wikimedia.org/wiki/Special:MyLanguage/Meta:OAuth_administrators
[7]: https://www.mediawiki.org/wiki/Manual:CORS
[8]: https://www.mediawiki.org/wiki/API:Cross-site_requests
[9]: https://phabricator.wikimedia.org/T322944
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2025-02): 222
Active Maniphest users (any activity) in (2025-02): 1096
Task authors in (2025-02): 564
Users who have closed tasks in (2025-02): 316
Projects which had at least one task moved from one column to another on
their workboard in (2025-02): 309
Tasks created in (2025-02): 2259
Tasks closed in (2025-02): 2163
Open and stalled tasks in total: 54600
* Only open tasks in total: 53510
* Only stalled tasks in total: 1090
Median age in days of open tasks by priority:
Unbreak now: 81
Needs Triage: 1120
High: 1404
Normal: 2194
Low: 2685
Lowest: 3378
(How long tasks have been open, not how long they have had that priority)
To see the names of the most active task authors:
* Go to https://wikimedia.biterg.io/
* Choose "Phabricator > Overview" from the top bar
* Adjust the time frame in the upper right corner to your needs
* See the author names in the "Submitters" panel
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on phab1004 at Sat 01 Mar 2025 12:00:45 AM UTC)