Hi everyone,
Do you want to present at Wikimania 2023 <https://www.wikimania.org>?
Wikimania program submissions are open now until the end of day Tuesday 28
March, anywhere on earth <https://zonestamp.toolforge.org/1680091140>.
After the 2020 edition of Wikimania was postponed and the two following
online editions, Wikimania is now back with an *in-person*, *hybrid* and
*on-demand* event in Singapore, from 16-19 August 2023!
The theme for Wikimania 2023 is *Diversity, Collaboration, Future*. There
are 11 tracks to choose from: familiar ones like Community Initiatives,
Governance, GLAM, or Technology; and new ones like Open Data and Wild
Ideas. You can submit an interactive workshop or panel, a lecture, a short
lighting talk or a poster for our dedicated poster session. Making a
submission is easy and we have upcoming conversation hours on Sunday March
19 at 00:00 and 14:00 UTC to help you out. You can also reach out to us on
the talk page or on Telegram. All the information you need is available on
wiki <https://wikimania.wikimedia.org/wiki/2023:Program/Submissions>.
To explore suggested topics for the track, please see here
<https://wikimania.wikimedia.org/wiki/2023:Program/Submissions#Tracks>: to
browse through the already submitted proposals, please go to the Program
Submission category
<https://wikimania.wikimedia.org/wiki/Category:Wikimania_2023_Program_submis…>
on the Wikimania wiki.
We welcome your session proposals. Read more on *Diff*
<https://diff.wikimedia.org/2023/02/28/be-part-of-the-wikimania-2023-program/>and
start preparing your ideas!
Kind regards,
*Ciell*
On behalf of the Wikimania 2023 Core Organizing Team
Hi,
Andre suggested mailing to this list about task T236671 [0]. It is about
a misleading error message issued when having senior moments and trying
to run "update.php against" a non-existing database.
The issue is not a big deal, but it may be possible to improve usability
without considerable effort. I cannot assess, though.
Thanks a lot for having a peep at this.
Cheers, Karsten
[0] https://phabricator.wikimedia.org/T236671
Hello,
I have deployed a change to Gerrit which makes it display the ongoing
CI/Zuul build if there is any.
If Jenkins jobs are running, you would see below the commit message some
gray chipset with the name of the Zuul pipeline (test, gate-and-submit
..). The Check tab shows the jobs details
(https://phabricator.wikimedia.org/F36925186).
By exposing the Zuul CI status directly in the Gerrit web UI, people
will notice a build error earlier. That also saves the hassle of having
to monitor https://integration.wikimedia.org/zuul/.
There are a few glitches:
* the way I have implemented it abuses the model proposed by Gerrit
and in progress jobs are always considered a SUCCESS but will be
marked as ERROR when they fail.
* code is entirely running in the client browser. It is unable to send
notifications or triggers any email when a build has failed. The
EarlyWarning bot by Kosta Harlan
<https://phabricator.wikimedia.org/J302> does it though)
* I am not a JavaScript developer per see but learned about TypeScript
for static analysis and rediscovered QUnit. So at least there are
some basic guarantees.
* there are surely a bunch of edge cases that I have not properly handled
The code for those that are curious is at
https://gerrit.wikimedia.org/g/operations/software/gerrit/+/refs/heads/depl…
If you see problems, JavaScript errors etc please paste them on
https://phabricator.wikimedia.org/T214068 :)
Antoine "hashar" Musso
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…