Wikimedia Phabricator tasks have a "Priority" dropdown field (which is
not consistently used) with several discrete values, among them
"Lowest". See [1] for the full list of Priority field values.
Since [2], "Low" and "Lowest" priority share the same definition.
I propose to disable setting the "Lowest" Priority value in Phab tasks.
"Lowest priority" can sound demotivating / disrespectful ("there is
nothing that could be even less important"). However, bikeshedding
about changing the name of the value would ignore further observations:
* About half of the people who are most active in setting initial
Priority values do not ever set Priority to "Lowest"[3].
* There is no significant difference between median age of open tasks
with Low and with Lowest priority[4], thus nothing seems to get
realistically differentiated here.
* Personally I also assume Lowest priority is sometimes used instead
of honestly declining a task (means: "this is not a good idea"[5]).
But of course that is rather hard to prove.
If you have opinions and/or ideas how to interpret data differently,
please add them to https://phabricator.wikimedia.org/T228759 to keep
them in a single place - either as a text comment, or via "Award Token"
to express support or disagreement without adding words.
Thanks,
andre
[1] https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_leve…
[2] https://phabricator.wikimedia.org/T317533
[3] https://phabricator.wikimedia.org/T228759#6988320
[4] https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…
[5] https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle
--
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/
The mission of Wikimedia Performance is for our sites to transcend socioeconomic barriers around reliable and fast access to find and contribute knowledge. We provide tools and expertise to empower developers, and directly inform or undertake high-yield engineering projects. [1][2]
The below is a periodic introduction and summary of recent changes to our guides. If you haven't read these before, or if it's been more than six months, I recommend taking a fresh look. Especially if you work on frontend or backend components in a MediaWiki extension or MediaWiki core.
== *Current best practices* ==
The practices guides help set direction. Use them to guide new developments, or to identify areas for improvement in current code. If you're short on time, focus on the "Getting started" section atop each guide.
*Frontend*: https://wikitech.wikimedia.org/wiki/Performance/Guides/Frontend_performance…
* The introduction details the principles that drive our platform's architecture, and how to get the most out of it.
* Changed: The CSS "@embed" optimisation is now only recommended for very small icons (up to 0.3KB). The guide explains why and how.
*Backend*: https://wikitech.wikimedia.org/wiki/Performance/Guides/Backend_performance_…
* New "Getting started" section, with pointers to specific chapters for detailed guidance.
* Rewritten "Shared resources" chapter, now with a more accessible explanation of MySQL deadlocks and how to avoid them.
* Update "Multi-datacenter deployment" guidance. (No changes are needed to existing code.) We first adopted Multi-DC practices in 2015. WANObjectCache and JobQueue interfaces have gotten simpler since. Cross-DC purges and job queuing "just work", with no awareness or responsibility on calling code. MediaWiki now automatically pins a browser to the primary DC for a few seconds after publishing an edit. This allowed us to remove cross-DC complexity around the ChronologyProtector <https://doc.wikimedia.org/mediawiki-core/master/php/classWikimedia_1_1Rdbms…>.
== *Measuring* ==
The new "measure" guides help assess performance of existing code, and can help iterate development of proposed changes.
Frontend includes browser dev tools and continuous monitoring through dedicated perf testing infrastructure:
https://wikitech.wikimedia.org/wiki/Performance/Guides/Measure_frontend_per…
Backend includes flame graphs, benchmarking, and automatic Grafana stats if you adopt WANObjectCache:
https://wikitech.wikimedia.org/wiki/Performance/Guides/Measure_backend_perf…
== *More* ==
The above guides and an overview of datasets, tools, recommended Grafana dashboards, and infrastructure diagrams are available at:
https://wikitech.wikimedia.org/wiki/Performance
On behalf of the Performance Team,
-- Timo Tijhof.
[1] https://techblog.wikimedia.org/2018/12/12/why-performance-matters/
[2] https://www.mediawiki.org/wiki/Wikimedia_Performance_Team#Mission
The 1.40.0-wmf.27 version of MediaWiki is blocked[0].
The new version is currently deployed to group1, but can proceed no
further until this issue is resolved or triaged as irrelevant:
* Lcobucci\JWT\Signer\InvalidKeyProvided: Key cannot be empty
- https://phabricator.wikimedia.org/T321160
Once these issues are resolved train can resume.
Thank you for any help resolving these issues!
-- Your humble train toilers
[0]. https://phabricator.wikimedia.org/T330205
[1]. https://versions.toolforge.org/
I wrote a post, "CI: Get notified immediately when a job fails"[0], about new CI notification options for MediaWiki core/extension/skin developers.
tl;dr, if you want to get notified as soon as any test fails (instead of waiting for the entire set of jobs to finish) this is now possible.
Thanks to Antoine Musso & Martin Urbanec for their collaboration and support on this!
Feedback & contributions to the feature are very welcome; see the blog post for details.
Cheers,
Kosta
[0] https://phabricator.wikimedia.org/phame/post/view/302/ci_get_notified_immed…
Hi everyone!
Inspired by https://www.mediawiki.org/wiki/VisualEditor/Gadgets#Implementing_a_custom_c… I was trying to add a `<br />` into the VE using this command:
```
ve.init.target.getSurface().getModel().getFragment().insertContent( [ { type: 'break' }, { type: '/break' } ] );
```
While it actually inserted the line break in visual edit mode, there was not `<br />` in the wikitext after saving the page or switching to wikitext mode within the edit session.
I also tried to implement the whole "command/tool" in an extension, but the behavior was the same. The odd thing is that a `<br />` inserted in wikitext mode survives the round trip. The linear data model shows it as "alienInline" node then.
Any ideas why the official example didn't work for me?
Greetings,
Robert
Hello all,
As you may already know, the Wikimedia Hackathon 2023 will take place in
Technopolis, Athens, Greece, on May 19-21. This in-person event will gather
the global Wikimedia technical community to connect, hack, run technical
discussions, and explore new ideas.
*If you plan to join, please register as soon as possible.*
Registration for the Hackathon will be open until we reach the event's
maximum capacity [0]. If you plan to join, we encourage you to register as
soon as possible, as there are currently around ten slots left. We also
encourage you to book your travel and accommodation shortly. You will find
more information on the travel [1] and accommodation [2] pages. You are
also welcome to help us improve those pages by adding additional
information about Athens and how to travel there.
For people who already registered, remember to confirm your attendance by
filling out the additional field in the registration form (see the email
sent by hackathon(a)wikimedia.org on March 13). Please note that WMF's
scholarship process concluded in January, and aside from the 51 people who
got a scholarship confirmed, we cannot support people with funds or visa
documents. Therefore, most participants must organize their own travel to
stay in Athens.
This year's edition will focus on bringing together people who already
contribute to technical aspects of the Wikimedia projects, know how to find
their way around in the technical ecosystem, and can work or collaborate on
projects more autonomously. For people new to our technical environment,
there are other newcomers-friendly events you can join throughout the year
- feel free to improve the list. [3]
*You can organize a satellite event with your local community.*
For people new to the technical aspects of the Wikimedia projects or who
cannot attend the in-person event, a great option could be to organize an
autonomous, local satellite event to the Hackathon. These events can occur
before, during, or after the in-person event. If you are considering
running an event like this, contact your local community to get started! If
you need financial support, please note that the deadline to apply for the
current round of Rapid Funds is March 20 [4].
*Proposals for the in-person program are welcome until April 4.*
The Hackathon is organized as a participant-driven event and lives from the
active participation of its attendees. Because this year's edition is
focused on reconnecting with your technical community peers in person, most
of the program will take place onsite. You can propose a session by
creating a task on the Phabricator board. Find more information on the
Program page [5].
Similar to the satellite events, some online sessions, in parallel or ahead
of the event, may be organized autonomously by participants. In any case,
participants are free to work on their projects, whether in-person or
online, and connect to the technical community on the Hackathon channels
[6].
If you have any questions, feel free to use the Hackathon talk page or to
reach out to the organizers at hackathon(a)wikimedia.org.
Cheers,
Srishti
On behalf of the Hackathon organizing team
[0]
https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Participate#Registr…
[1] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Travel
[2] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Accommodation
[3] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Documentation#Event…
[4] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Satellite_events
[5] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Program
[6] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Connect
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
This Tuesday, Mar 14, at 21:00 UTC (14:00 PDT), we're planning a window
for updates to the production Phabricator instance. While we've
reserved 2 hours out of an abundance of caution, we intend for the
actual downtime to be much shorter.
This window is contingent on the status of the weekly deployment train.
If something important is broken in production, we'll push it to a later
date.
This update should include several minor UI improvements, but does not
otherwise change the code.
There's a Phab task for this release; as usual we'll track the work on
Etherpad and #wikimedia-operations once underway:
https://phabricator.wikimedia.org/T331915
Thanks,
--
Brennen Bearnes
Release Engineering
Wikimedia Foundation
Hey all,
This is a quick note to highlight that in six weeks' time, the REL1_40
branch will be created for MediaWiki core and each of the extensions and
skins in Wikimedia git, with some (the 'tarball') included as sub-modules
of MediaWiki itself[0]. This is the first step in the release process for
MediaWiki 1.40, which should be out in May 2023, approximately six months
after MediaWiki 1.39.
The branches will reflect the code as of the last 'alpha' branch for the
release, 1.40.0-wmf.27, which will be deployed to Wikimedia wikis in the
week beginning 13 March 2023 for MediaWiki itself and those extensions
and skins available there.
After that point, patches that land in the main development branch of
MediaWiki and its bundled extensions and skins will be slated for the
MediaWiki 1.41 release unless specifically backported[1].
If you are working on a new feature that you wish to land for the release,
you now have a few days to finish your work and land it in the development
branch; feature changes should not be backported except in an urgent case.
If your work might not be complete in time, and yet should block release
for everyone else, please file a task against the `mw-1.40-release` project
on Phabricator.[2]
If you have tickets that are already tagged for `mw-1.40-release`, please
finish them, untag them, or reach out to get them resolved in the next few
weeks.
We hope to issue the first release candidate, 1.40.0-rc.0, two weeks after
the branch point, and if all goes well, to release MediaWiki 1.40.0 a few
weeks after that.
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
[0]: <https://www.mediawiki.org/wiki/Bundled_extensions_and_skins>
[1]: <https://www.mediawiki.org/wiki/Backporting_fixes>
[2]: <https://phabricator.wikimedia.org/tag/mw-1.40-release/>