February 2024 - MediaWiki-l - lists.wikimedia.org

MediaWiki-l February 2024

mediawiki-l@lists.wikimedia.org

5 participants
5 discussions

by Birgit Muller

Hi All, welcome to the monthly MediaWiki Insights email! Like last time < https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/January_2… >, we’re starting this email by celebrating volunteer contributors who got their first patch merged in MW core, WMF deployed extensions or services over the past month: A big thanks to GergesShamon and Agent Isai for their contributions! Welcome :-) Many thanks also to the reviewers - volunteers and staff - of patches by new contributors. Your support is invaluable for helping people contribute to MediaWiki effectively and make it a fun first experience! The focus of this edition of the monthly MW Insights email lies on our multi-year initiatives: Migration of MediaWiki from bare metal to Kubernetes < https://wikitech.wikimedia.org/wiki/MediaWiki_On_Kubernetes > in Wikimedia Production, Parser Unification < https://www.mediawiki.org/wiki/Parsoid/Parser_Unification > and RESTBase deprecation < https://phabricator.wikimedia.org/project/profile/6289/ >. These initiatives involve many people and projects, require orchestrated efforts and coordination, and will help us in many different ways. Another thing that these initiatives have in common is that we’re getting closer to being able to benefit from these efforts :-). Project Snapshots: Milestones reached on 3 multi-year projects MediaWiki on Kubernetes migration is 75% complete, completing migration of all internal traffic, all scheduled jobs and reaches 50% global traffic milestone! Often shortened as mw-on-k8s, MediaWiki on Kubernetes is a multi-year effort to move all of the MediaWiki deployments running on WMF production infrastructure to the new WikiKube platform. The migration is underway and very recently a new milestone was hit where the WikiKube platform now serves 50% of end user requests < https://phabricator.wikimedia.org/T290536 >. At half mark, having more percentage of traffic on WikiKube, Service Operations is working with Release Engineering to make changes to monitoring tools to surface any issues during deployments to continue with further ramps. Also, almost the entirety of what is called internal traffic < https://phabricator.wikimedia.org/T333120 >, that is traffic that is generated by applications running in the infrastructure and reaching out to MediaWiki for various purposes is migrated to WikiKube. A special mention should go to MediaWiki Jobs fully migrated just a week ago < https://phabricator.wikimedia.org/T349796 >. Feel free to follow the higher umbrella task < https://phabricator.wikimedia.org/T290536 > and/or MediaWiki_On_Kubernetes on Wikitech < https://wikitech.wikimedia.org/wiki/MediaWiki_On_Kubernetes >. This migration will unleash the ability to deploy multiple versions of code simultaneously. Also, this will help enhance platform capabilities to build dockerized isolated environments for coding, testing and even production debugging. MediaWiki on Kubernetes will allow us to deprecate and eventually remove a lot of our in-house developed code. Another benefit is that we will be able to react to sudden traffic spikes, like newsworthy events better, as the flexing up and down is a matter of configuration change. This enables efficient placement of workloads, packing workloads in a more environmentally friendly way, increasing hardware utilization. It takes a village to get this far: A big thanks to the Service Operations team (Clement Goubert, Giuseppe Lavagetto, Alexandros Kosiaris, Kamila Sou?kova, Hugh Nowlan, Effie Mouzeli, Reuven Lazarus, Jannis Mayboom and Kavitha Appakayala) for their leadership on this project, the Release Engineering team (specifically: Dan Duvall, Jeena Huneidi, Tyler Cipriani and Ahmon Dancy) for their work on Blubber < https://wikitech.wikimedia.org/wiki/Blubber >, the Deployment Pipeline < https://wikitech.wikimedia.org/wiki/Deployment_pipeline > and Scap < https://wikitech.wikimedia.org/wiki/Scap >, Dom Walden from Quality and Test Engineering for crafting and executing a plan to test the first deployment of MediaWiki on Kubernetes, and everyone else who has contributed in the one way or the other! <3 More milestones: We’re seeing the first lights at the end of the tunnel of another multi-year initiative: The *parser unification* < https://www.mediawiki.org/wiki/Parsoid/Parser_Unification >. One week ago, Parsoid Read Views was rolled out to first wikis: Parsoid is now the default read views renderer on the Foundations’ Office Wiki and Wikitech DiscussionTools. This early experimentation allows us to find issues in a limited space, which will help us evaluate readiness of the feature and increase our confidence for future rollouts < http://mediawiki.org/wiki/Parsoid/Parser_Unification/Confidence_Framework >. A huge thanks to Subbu Sastry, Mateus Santos, CScott, Isabelle Hubert-Pallatin, Arlo Breault, Shannon Bailey, Yiannis Giannelos and Sergio Lopes for making this work! Many thanks also to Daniel Kinzler: His work on the RESTBase deprecation directly helped us get to this milestone :-) *RESTBase deprecation*: We have been continuously working on decoupling services from RESTBase, aiming for the modernisation and sustainability of Wikimedia products in our services platform. The MediaWiki Interfaces team finished up reimplementation of Reading Lists endpoints in MW REST API < https://phabricator.wikimedia.org/T348491 > and are now confirming with affected callers < https://phabricator.wikimedia.org/T357478 > that the new endpoints meet their needs before rerouting calls < https://phabricator.wikimedia.org/T348493 > and retiring old code < https://phabricator.wikimedia.org/T348494 >. The overall effort < https://phabricator.wikimedia.org/T336693 > will not only move us forward on RESTBase retirement, but also reduce the total amount of code we have to maintain. Many thanks to Bill Pirkle, Atieno Njira, Wendy Quarshie, and Daniel Kinzler for making this work! We also fully turned off Parsoid cache storage in RESTBase - clients will get outputs direct from MediaWiki and the cache will be handled by ParserCache. Next, we will re-route clients directly to MediaWiki and fully remove Parsoid from RESTBase (T344944 < https://phabricator.wikimedia.org/T344944 >). The Page Content Service (PCS) will also handle its own cache < https://phabricator.wikimedia.org/T348995 > and we are ready to test the new capabilities in staging soon. Many thanks to Yiannis Giannelos and the Content Transform team and to Daniel Kinzler for his efforts and support on decoupling Parsoid from RESTBase! All of these multi-year initiatives help us increase sustainability and maintainability of the platform, streamline engineering and developer workflows, and unlock the path for new and improved platform capabilities and product opportunities. Outlook: Knowledge Platform in the annual plan 2024/2025 The Wikimedia Foundation has recently published the draft objectives by the Product & Technology department < https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/… > for the next annual plan on Meta, alongside an introduction by Selena Deckelmann and a few questions that we’re exploring < https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_Annual_Plan/2024-… >. Your input on these questions is very welcome! The draft objectives include “Knowledge Platform I” - centered around MediaWiki platform evolution and “Knowledge Platform II” - centered around developer/engineering services and workflows. The objectives show only the high-level direction for next year. The draft “key results” (currently work in progress) will give a better idea of what areas of work we’re thinking about. We’ll be publishing these in March and share the link + invitation for feedback with this list again. Thanks all for reading, Birgit -- Birgit Muller (she/her) Director of Product, MediaWiki and Developer Experiences Wikimedia Foundation < https://wikimediafoundation.org/ >

3?months

Error: Call to undefined method WikiPage::doEditContent() in runJob.php for pages Imported with ImportCSV for MediaWiki 1.39.5, SemanticMedia 4.1.3

by dave＠protoball.org

I'm looking for help getting Semantic Mediawiki ImportData to work in MediaWiki 1.39.5, SemanticMedia 4.1.3 My CSV job starts successfully, but then I get an error in runJobs.php "Error: Call to undefined method WikiPage::doEditContent()"

3?months

Call for Contributions - MediaWiki Users and Developers Conference

by Cindy Cicalese

Greetings, MediaWiki users and developers! We are now accepting contributions for the 2024 MediaWiki Users and Developers Conference [0], which will be held April 17-19 in Portland, OR, USA. The deadline to submit a proposal is March 22. Sign up as soon as possible at [1]. This will primarily be an in-person conference, however we will consider remote presentations on a case-by-case basis.The first two days of the conference will be reserved for presentations. The third day of the conference will be a Create Camp, which will include tutorials, hands-on presentations, and small group hacking sessions. The MediaWiki Users and Developers Conference, formerly EMWCon, brings together the community that makes up MediaWiki ? those who develop for MediaWiki, those who deploy MediaWiki, and those who use MediaWiki and are enthusiastic about the software. MediaWiki is used every day in a variety of contexts ? educational projects, corporate knowledge bases, even online hobbyist communities ? all valuing MediaWiki for its flexibility and its openness. By meeting together we can learn from our experiences and continue to build a true community of support for MediaWiki. Looking forward to seeing you in Portland! - The MediaWiki Users and Developers Conference Organizing Committee: James Hare - Conference Chair Cindy Cicalese - Program Chair Bryan Hilderbrand - Registration Chair Jeffrey Wang - Social Chair Ike Hecht - Sponsor Chair Ryan Schmidt - Technology Chair [0] https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20… [1] https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…

3?months, 1?week

MediaWiki Users and Developers Conference 2024 Call for Participation and Presentations

by James Hare

We are pleased to announce the first MediaWiki Users and Developers Conference [0], the successor to EMWCon. The conference will be held in Portland, Oregon, from April 17?19 at the Jupiter NEXT Hotel [1]. The MediaWiki Users and Developers Conference brings together the community that makes up MediaWiki ? those who develop for MediaWiki, those who deploy MediaWiki, and those who use MediaWiki and are enthusiastic about the software. MediaWiki is used every day in a variety of contexts ? educational projects, corporate knowledge bases, even online hobbyist communities ? all valuing MediaWiki for its flexibility and its openness. By meeting together we can learn from our experiences and continue to build a true community of support for MediaWiki. Registration is open now. [2] Register soon to take advantage of the early bird discount! See the conference page for local accommodations. [3] Everyone who is attending is encouraged to stay at either of these hotels, where we have negotiated group rates. If you have ideas for the program, add them to the wiki page. [4] While this will primarily be an in-person conference, we will consider remote presentations on a case-by-case basis. Looking forward to seeing you in Portland! Best regards, the MediaWiki Users and Developers Conference Organizing Team [0]? https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20… [1]? https://www.jupiterhotel.com/the-next [2]? https://www.eventbrite.com/e/mediawiki-users-and-developers-conference-spri… [3]? https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20… [4]? https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…

4?months

MediaWiki Insights - December/January double edition

by Birgit Muller

Hi All, Happy 2024 and welcome to the monthly MediaWiki Insights email! We’re starting this year with celebrating contributors who got their first patch merged in MW core, WMF deployed extensions or services in the months of December and January: A big thanks to Do?u Abaris, apasternak, Abador, Mehdi Zidani, Oudedutchman, Cyn, Dominic mayers, and Houseblaster for their contributions! Welcome :-) Enable more people to know MediaWiki and contribute effectively As shared in the previous MW insights email < https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/November_… >, we have been thinking about ways to improve first time MediaWiki (core) contributors’ experience. One key part of that is knowing who is new to be able to say hi (and thank you). Bartosz created a script < https://gitlab.wikimedia.org/matmarex/gerrit-new-contributors/-/blob/master… > to find new MediaWiki contributors for a given month that got their first patch merged (see above!). Another key part is code review for patches submitted by (new) volunteer contributors. We’re currently thinking about how we could organize code review for volunteer-submitted patches better across MediaWiki Engineering and want to give a shared MW-Engineering Gerrit dashboard a try, with primary focus on the components the group is responsible for. We ran a WMF-internal MediaWiki CodeJam event < https://www.mediawiki.org/wiki/MediaWiki_Code_Jam#Results > in December, with 54 participants (16 from the MW team) and 21 Phabricator tickets completed. Areas of improvement included MediaWiki itself and multiple essential extensions. See the project page for details! Two notable “side projects” of the CodeJam: To support new contributors, Timo has created a series of tutorials < https://www.mediawiki.org/wiki/User:Krinkle/MediaWiki_Introduction_2023 > going over core MediaWiki concepts. The videos are also available on youtube (part I: MediaWiki core concepts < https://www.youtube.com/watch?v=-JnIjpRvgNY >, part II: Wikipedia’s extensions < https://www.youtube.com/watch?v=4xYbqbabTwI >). A "Quick" MW install < https://www.mediawiki.org/wiki/Local_development_quickstart > was created to make it possible to install MediaWiki in 3 steps and under 5 minutes. See this ticket for the evaluation < https://phabricator.wikimedia.org/T348899 > on how this worked out for testers during code jam. Thanks to Alex Paskulin, Timo Tijhof and Kosta Harlan for their work <3 The materials as well as lessons learned from this first MW code jam will help us run a second edition for everyone who’s interested, possibly ahead of, and at the Wikimedia Hackathon < https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024 >. Project snapshot: Virtual domains, great namespaceisation, and first MW Engineering cross-sub-team quarterly planning We finalized the Q3 plan (= Jan-March) for MediaWiki Engineering in early January. This is the first time where we applied a “cross-sub-team” planning approach across MediaWiki Engineering & engaged as a group on gathering proposals and then prioritized these. A few examples for high priority work: - Evolve central login to meet requirements of a changing environment (“SUL3”): T348388 < https://phabricator.wikimedia.org/T348388 > - Support upgrade of WMF production from PHP 7.4 to 8.1: T319432 < https://phabricator.wikimedia.org/T319432 > - Continue work to move off RESTBase < https://phabricator.wikimedia.org/project/profile/6289/ > - Continue work on exploring how essential workflows on the Wikimedia projects are currently supported through the MediaWiki software ecosystem (see below) - Prepare MW-platform team owned components < https://phabricator.wikimedia.org/T355377 > for compatibility with the upcoming Temporary Accounts for Unregistered Editors < https://www.mediawiki.org/wiki/Help:Temporary_accounts > project. We’ve already checked the box on preparing auth components < https://phabricator.wikimedia.org/T326925 > (OATHAuth and WebAuthn) for compatibility - many thanks to Piotr and Gergo for their work on this! Other highlights: - We’ve made progress towards supporting Less 3.13 < https://phabricator.wikimedia.org/T288498 > behavior: A series of bugs were fixed in Less v2.5.3 to pave the way to enable new Less.js capabilities to be used in the frontend. - The Content Transform team has moved functionality out of Parsoid and into Cite extension < https://phabricator.wikimedia.org/T354215 >, which allows both Parsoid and the default parser to use the same underlying functionality and reduce maintenance burdens. - To support SRE’s work, MediaWiki metrics were migrated from Graphite to Prometheus. This is an ongoing effort with more upcoming work. - Cleanup continued in dropping deprecated unused config variables < https://phabricator.wikimedia.org/T166010 > (also known as the great namespaceisation effort). - Virtual domains are now working well in MediaWiki core < https://phabricator.wikimedia.org/T353948 > and are supported in the updater and installer. - A minor task was to update the JavaScript syntax checker for gadgets and user scripts for ES6 and ES7 < https://phabricator.wikimedia.org/T75714 >. - Database: Amir Sarabadani presented < https://commons.wikimedia.org/wiki/File:Major_changes_to_MediaWiki%27s_rdbm… > about changes done to the RDBMS library at SMW Con (video available < https://www.youtube.com/watch?v=q0mjNEJP5Fo >). DBAccessObjectUtils is being redesigned < https://phabricator.wikimedia.org/T354194 >, including major deprecation of indirect calls to IDBAccessObject constants. How essential workflows are served through the MediaWiki software ecosystem As part of developing a product strategy for MediaWiki, one research question is how the MediaWiki software ecosystem currently supports essential workflows on the Wikimedia projects. We also wanted to understand commonalities and differences in how these workflows and use cases are supported on different wikis - for example, Wikipedia A vs Wikipedia B, Wikipedia A vs Wikidata, or Wikipedia A vs translatewiki.net - etc. Moriel has been leading this work, in collaboration with many engineers across different areas of expertise. A first outcome has now been published: Unraveling Complexity: Mapping MediaWiki Software Components into User-Driven Workflows < https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/Unravel… > The next outcome is already in the making, with focus on exploring how specific use cases are supported (differently) on 3 different Wikimedia projects. The goal is to identify where conceptual behaviors diverge and converge between the wikis, pinpointing base and common behaviors versus those unique to specific cases. This brings us in the interesting fields of software behavior on use cases such as: “An unregistered (not yet temporary) user edits existing wikitext content (fixing typo) on desktop.” Read the write-up above to learn more about why, and stay tuned for the next outcome of this exploration, which will talk through some of the findings in this multi-wiki modeling approach. Thanks all for reading! Birgit -- Birgit Muller (she/her) Director of Product, MediaWiki and Developer Experiences Wikimedia Foundation < https://wikimediafoundation.org/ >

4?months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l February 2024