Hello,
The continuous integration server contint2001 will be restarted for a
hardware maintenance on Tuesday January 18th at 16:00 UTC. During the
maintenance, the CI systems will be unavailable:
- Jenkins
- Zuul
- https://integration.wikimedia.org/
The out-of-band management system requires an update to address
intermittent loss of connectivity. We have to restart the server.
Time conversions:
PST 8:00
CT 10:00
UTC 16:00
CET 17:00
The task is:
https://phabricator.wikimedia.org/T283582
cheers,
--
Antoine "hashar" Musso
How’d we do in our strive for operational excellence last month? Read on to find out!
Incidents
One documented incident last month (Incident graphs <https://codepen.io/Krinkle/full/wbYMZK>).
2021-12-03 mx <https://wikitech.wikimedia.org/wiki/Incident_documentation/2021-12-03_mx>
Impact: A portion of outgoing email from wikimedia.org was delivered with a delay of upto 24 hours. This affected staff Gmail, and Znuny/Phabricator notifications. No mail was lost, it was eventually delivered.
Incident follow-up
Remember to review and schedule Incident Follow-up work <https://phabricator.wikimedia.org/project/view/4758/> in Phabricator. These are preventive measures and tech debt mitigations written down after an incident. Read about past incidents at Incident status <https://wikitech.wikimedia.org/wiki/Incident_status> on Wikitech.
Recently resolved incident follow-up:
Create paging alert for high MX queues <https://phabricator.wikimedia.org/T297144>.
Filed in December after the mail delivery incident, resolved later that month by Keith (Herron).
Limit db execution time of expensive MW special pages <https://phabricator.wikimedia.org/T297708>.
Filed in December after various incidents due to high DB/appserver load, carried out by Amir (Ladsgroup).
Trends
In December we reported 22 new errors in December <https://phabricator.wikimedia.org/maniphest/query/DhZaBJ5PI1NA/#R>, of which 5 have since been resolved, and 17 remain open and have carried over to January. From the 298 issues previously carried over, we also resolved 17, thus the workboard still adds up to 298 in total.
In previous editions, we sometimes looked at the breakdown of tasks that remained unresolved. This time, I'd like to draw attention to the throughput and distribution of tasks that did get resolved.
Production errors resolved in the month of December, by team and component (query <https://phabricator.wikimedia.org/maniphest/query/vIEXYsei8lwE/#R>):
* Community-Tech (2): GlobalPreferences (1), CodeMirror (1).
* DBA: DjVuHandler (1).
* Editing-team: DiscussionTools (1).
* Fundraising Tech: CentralNotice (1).
* Growth-Team (8): GrowthExperiments (6), Image-Suggestions (1), StructuredDiscussions (1).
* Language-Team: UniversalLanguageSelector (1).
* Parsoid (1).
* Product-Infrastructure: TemplateStyles (1).
* Readers-Web (2).
* Structured-Data (2).
* Wikidata team: Wikidata-Page-Banner (1).
* Missing steward (1): MediaWiki-Logevents (T289806: Thanks Umherirrender!).
For the month-over-month numbers, refer to the spreadsheet data <https://docs.google.com/spreadsheets/d/e/2PACX-1vTrUCAI10hIroYDU-i5_8s7pony…>.
Outstanding errors
Oldest unresolved errors:
* (June 2020) WikibaseClient: RuntimeException in wblistentityusage API. T254334 <https://phabricator.wikimedia.org/T254334>
* (June 2020) WikibaseClient: Deadlock in EntityUsageTable::addUsages method. T255706 <https://phabricator.wikimedia.org/T255706>
Take a look at the workboard and look for tasks that could use your help.
→ https://phabricator.wikimedia.org/tag/wikimedia-production-error/
Thanks!
Thank you to everyone who helped by reporting, investigating, or resolving problems in Wikimedia production. Thanks!
Until next time,
– Timo Tijhof
🔗 Share or read later via https://phabricator.wikimedia.org/phame/post/view/265/
Respected sir/madam,
I am Huda Saleem, a computer science undergrad, at Barani Institute of
Sciences Sahiwal. I am new to open source contributions. But I am well
aware of Frontend and Backend Technologies like HTML, CSS, JavaScript and
PHP. Also, I am a python developer too. I would love to contribute to your
organization but could you please tell me how to get started?
Hoping to hear from you soon.
Kind Regards
Huda Saleem
The 1.38.0-wmf.17 version of MediaWiki is being held at group0[0] due to a large
spike in parser errors on commons and group1 wikipedias upon deployment.
The new version is deployed to group0[1], but can proceed no
further until these issues are resolved:
* T299149 - MWException: Parser state cleared while parsing. Did you
call Parser::parse recursively?
Once these issues are resolved, the train can move forward.
Thank you for your help!
-- Your humble train toiler
[0]. <https://phabricator.wikimedia.org/T299149>
[1]. <https://versions.toolforge.org/>
--
Dan Duvall
Staff Software Engineer, Release Engineering
Wikimedia Foundation
Wikitech-l,
Hello. I have a question about the HTML output of wiki parsers. I wonder about how simple or complex that it would be for a wiki parser to output, instead of a flat document structure inside of a <div> element, an <article> element containing nested <section> elements?
Recently, in the Community Wishlist Survey Sandbox<https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Sandbox>, the speech synthesis of Wikipedia articles<https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Sandbox#Spoken_ar…> was broached. The proposer of these ideas indicated that, for best results, some content, e.g., “See also” sections, should not be synthesized.
In response to these interesting ideas, I mentioned some ideas from EPUB, referencing pronunciation lexicons from HTML<https://www.w3.org/publishing/epub3/epub-contentdocs.html#sec-pls> and SSML attributes in HTML<https://www.w3.org/publishing/epub3/epub-contentdocs.html#sec-xhtml-ssml-at…>, the CSS Speech Module<https://www.w3.org/TR/css-speech-1/>, and that output HTML content could be styled using the CSS Speech Module’s speak property.
In these regards, I started thinking about how one might extend wikitext syntax to be able to style sections, e.g.,:
== See also == {style="speak:never"}
Next, I inspected the HTML of some Wikipedia articles and realized that, due to the structure of the output HTML documents, it isn’t simple to style or to add attributes to sections. There are only <h2>, <h3>, <h4> (et cetera) elements inside of a containing <div> element; sections are not yet structured elements.
The gist is that, instead of outputting HTML like:
<div class="mw-parser-output">
<h2><span class="mw-headline" id="Heading">Heading</span></h2>
<p>Paragraph 1</p>
<p>Paragraph 2</p>
<h3><span class="mw-headline" id="Subheading">Subheading</span></h3>
<p>Paragraph 3</p>
<p>Paragraph 4</p>
</div>
could a wiki parser output HTML5 like:
<article class="mw-parser-output">
<section id="Heading">
<header><h2><span class="mw-headline">Heading</span></h2></header>
<p>Paragraph 1</p>
<p>Paragraph 2</p>
<section id="Subheading">
<header><h3><span class="mw-headline">Subheading</span></h3></header>
<p>Paragraph 3</p>
<p>Paragraph 4</p>
</section>
</section>
</article>
Initial thoughts regarding the latter HTML5 include that it is better structured, more semantic, more styleable, and potentially more accessible. If there is any interest, I could write up some lengthier discussion about one versus the other, why one might be better – and more useful – than the other.
Is this the correct mailing list to discuss any of these wiki technology, wiki parsing, wikitext, document model, and HTML5 output topics?
Best regards,
Adam