Dear MediaWiki community.
we are happy to announce the program for the first European MediaWiki Users and Developers Conference is out: https://conference.knowledge.wiki
The program covers a wide range of topics from MediaWiki community and development aspects, business and government use cases as well as MediaWiki in research and GLAM settings.
There are still seats left for participation in Vienna, so please make sure to book tickets at https://mwstake.eventbrite.com/
We want to express our gratitude to our sponsors!
Gold Sponsors:
https://bluespice.com/ Hallo Welt! - The company behind BlueSpice, the open-source enterprise wiki software
https://gesinn.it/ - gesinn.it GmbH & Co. KG. We develop software that makes knowledge accessible and information work more productive.
https://www.wikiteq.com/ - WikiTeq. MediaWiki Built for your Business
Silver Sponsors:
https://professional.wiki/ and https://wikibase-solutions.com/
See you in one month in Vienna!
Best,
Bernhard Krabina - general chair
Sabine Melnicki - program chair
Daniel Dobriy - online chair
Dear Tool Maintainers of Toolforge,
The idea for Tool-Watch <https://tool-watch.toolforge.org/> originated
during the Wikimania Hackathon 2023. A group of us was exploring various
tools from Toolhub and noticed that many of the links we clicked were not
functioning. This sparked our interest in finding an existing monitoring
tool for tools at Toolforge, but we were unable to locate one. Motivated by
this experience, we began developing Tool-Watch, which has been live for
some time now.
As part of this initiative, we are considering implementing email
notifications for tool maintainers. The goal is to notify maintainers if
their tool has been down for an extended period, allowing for timely
intervention and maintenance. We believe this will help keep our tools
running smoothly and reduce unnecessary infrastructure costs and make the
catalogue cleaner.
We value your input and would love to hear your thoughts on this topic.
Specifically, we’d like to know:
- Would you find email notifications helpful if they are triggered only
after extended downtime?
- Should the notification be triggered after 3, 7, or 30 days of
downtime? Or do you have any other time frame in mind?
Please feel free to share your feedback by replying to this email or
joining the discussion on Phabricator T368816#10201603
<https://phabricator.wikimedia.org/T368816#10201603>.
Also, special thanks to Soham and other contributors for supporting me in
building this tool!
Tool: https://tool-watch.toolforge.org/
Phabricator discussion: https://phabricator.wikimedia.org/T368816
Thank you for your continued support and dedication to our community. We
look forward to hearing from you!
Regards,
Gopa Vasanth <https://gopavasanth.github.io/>
Twitter <https://twitter.com/gopavasanth1999> | LinkedIn
<https://www.linkedin.com/in/gopa-vasanth/> | GitHub
<https://github.com/gopavasanth> | Gerrit
<https://gerrit.wikimedia.org/r/#/q/gopavasanth>
“Yesterday is not ours to recover, but tomorrow is ours to win or lose.”
How do we maintain the redirects for LL.wiki for the two-letter language
codes?
I recall these were gifted as a set to wikimedia, but currently don't seem
to work.
We have en-wp.org for English, but it is also not configured properly:
en-wp.org/TLDs redirects to en.wikipedia.org/TLDs and returns the error
We could not find the above page on our servers.
*Did you mean: /wiki/TLDs <https://en.wikipedia.org/wiki/ABCC11>*
--
Samuel Klein @metasj w:user:sj +1 617 529 4266
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, October 2, 2024
Time: 15:00-16:00 UTC / 08:00 PDT / 11:00 EDT / 17:00 CEST
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,
You're probably familiar with the mw.Api JavaScript class
<https://doc.wikimedia.org/mediawiki-core/master/js/mw.Api.html>
provided by MediaWiki, which can be used to make requests to our action API.
promise = ( new mw.Api() ).get( /*...*/ );
You may also know that the promises it returns are enhanced with an
.abort() method, which cancels the underlying HTTP request and rejects
the promise.
promise.abort();
The problem is that this method is only available on the original
promise object. If you try to chain promises, it no longer works:
promise.then( /*...*/ ).abort(); // Error: abort is not a function
Copying this method to the chained promise is very cumbersome. I will
spare you an example, but you can find it in the Phabricator task I
filed for this problem: T346984
<https://phabricator.wikimedia.org/T346984>. It's also not possible to
do if you use async/await, which we'll hopefully be able to use in
MediaWiki code soon.
The designers of the HTML5 Fetch API
<https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API> came up
with a different solution to the problem of cancelling HTTP requests:
abort signals
<https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#canc…>.
The Fetch API is increasingly being used outside of the MediaWiki world,
and so I would like to enhance our mw.Api to support the same approach.
*Here's my proposal:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/959350*
As you can tell by the six-digit patch number, I've had a hard time
finding anyone else interested in this, so I'm sending out this call for
reviewers. I hope there's someone out there with review rights who likes
the idea as well :)
You can read the documentation with examples of the new style here:
https://patchdemo.wmcloud.org/wikis/ee373520a4/w/docs/js/mw.Api-AbortContro…
The.abort() method is not being removed, and as a bonus, the patch
includes improved documentation for that style of cancellable promises:
https://patchdemo.wmcloud.org/wikis/ee373520a4/w/docs/js/mw.Api-AbortablePr…
--
Bartosz Dziewoński
Hi all,
With MediaWiki at the WMF moving to Kubernetes, it's now time to start
running manual maintenance scripts there. Any time you would previously SSH
to a mwmaint host and run mwscript, follow these steps instead. The old way
will continue working for a little while, but it will be going away.
What's familiar:
Starting a maintenance script looks like this:
rzl@deploy2002:~$ mwscript-k8s --comment="T341553" -- Version.php
--wiki=enwiki
Any options for the mwscript-k8s tool, as described below, go before the --.
After the --, the first argument is the script name; everything else is
passed to the script. This is the same as you're used to passing to
mwscript.
What's different:
- Run mwscript-k8s on a deployment host, not the maintenance host. Either
deployment host will work; your job will automatically run in whichever
data center is active, so you no longer need to change hosts when there’s a
switchover.
- You don't need a tmux. By default the tool launches your maintenance
script and exits immediately, without waiting for your job to finish. If
you log out of the deployment host, your job keeps running on the
Kubernetes cluster.
- Kubernetes saves the maintenance script's output for seven days after
completion. By default, mwscript-k8s prints a kubectl command that you (or
anyone else) can paste and run to monitor the output or save it to a file.
- As a convenience, you can pass -f (--follow) to mwscript-k8s to immediately
begin tailing the script output. If you like, you can do this inside a tmux
and keep the same workflow as before. Either way, you can safely disconnect
and your script will continue running on Kubernetes.
rzl@deploy2002:~$ mwscript-k8s -f -- Version.php --wiki=testwiki
[...]
MediaWiki version: 1.43.0-wmf.24 LTS (built: 22:35, 23 September 2024)
- For scripts that take input on stdin, you can pass --attach to
mwscript-k8s, either interactively or in a pipeline.
rzl@deploy2002:~$ mwscript-k8s --attach -- shell.php --wiki=testwiki
[...]
Psy Shell v0.12.3 (PHP 7.4.33 — cli) by Justin Hileman
> $wmgRealm
= "production"
>
rzl@deploy2002:~$ cat example_url.txt | mwscript-k8s --attach --
purgeList.php
[...]
Purging 1 urls
Done!
- Your maintenance script runs in a Docker container which will not outlive
it, so it can't save persistent files to disk. Ensure your script logs its
important output to stdout, or persists it in a database or other remote
storage.
- The --comment flag sets an optional (but encouraged) descriptive label,
such as a task number.
- Using standard kubectl commands[1][2], you can check the status, and view
the output, of your running jobs or anyone else's. (Example: `kube_env
mw-script codfw; kubectl get pod -l username=rzl`)
[1]: https://wikitech.wikimedia.org/wiki/Kubernetes/Kubectl
[2]: https://kubernetes.io/docs/reference/kubectl/quick-reference/
What's not supported yet:
- Maintenance scripts launched automatically on a timer. We're working on
migrating them -- for now, this is for one-off scripts launched by hand.
- If your job is interrupted (e.g. by hardware problems), Kubernetes can
automatically move it to another machine and restart it, babysitting it
until it completes. But we only want to do that if your job is safe to
restart. So by default, if your job is interrupted, it will stay stopped
until you restart it yourself. Soon, we'll add an option to declare "this
is idempotent, please restart it as needed" and that design is recommended
for new scripts.
- No support yet for mwscriptwikiset, foreachwiki, foreachwikiindblist,
etc, but we'll add similar functionality as flags to mwscript_k8s.
Your feedback:
Let me know by email or IRC, or on Phab (T341553
<https://phabricator.wikimedia.org/T341553>). If mwscript-k8s doesn't work
for you, for now you can fall back to using the mwmaint hosts as before --
but they will be going away. Please report any problems sooner rather than
later, so that we can ensure the new system meets your needs before that
happens.
Thanks,
Reuven, for Service Ops SRE
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2024-09): 198
Active Maniphest users (any activity) in (2024-09): 979
Task authors in (2024-09): 539
Users who have closed tasks in (2024-09): 278
Projects which had at least one task moved from one column to another on
their workboard in (2024-09): 299
Tasks created in (2024-09): 2334
Tasks closed in (2024-09): 2244
Open and stalled tasks in total: 54286
* Only open tasks in total: 53228
* Only stalled tasks in total: 1058
Median age in days of open tasks by priority:
Unbreak now: 72
Needs Triage: 1067
High: 1349
Normal: 2116
Low: 2648
Lowest: 3225
(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 Tue 01 Oct 2024 12:00:28 AM UTC)