Wikitech-l March 2023

wikitech-l@lists.wikimedia.org

51 participants
44 discussions

Followup: Technical Decision Making Retro
by Moriel Schottlender 31 Mar '23

31 Mar '23

Hello all, Following up on Tajh’s announcement email, the TDMP Retro team would like to invite you to engage with us on this retro process. As was mentioned, this retro will open the door for input from varied stakeholders and input will be requested through multiple venues, to make sure all stakeholders are able to contribute to the conversation. As a first step, the core team would like to invite you to read our planning document <https://www.mediawiki.org/wiki/Technical_decision_making/Technical_Decision…>, and offer insights <https://www.mediawiki.org/wiki/Talk:Technical_decision_making/Technical_Dec…> on the administrative side of this retro process: - Are there any stakeholders we have left out? - Any unclear parts of the retro process? - What communication channels are important for engagement in the retro process? Ex: Mailing list, Talk pages, IRC, other? We will soon start working towards the next steps, which will delve into the substantive input about the process from all stakeholders. We are hopeful that this process will enable and encourage all voices to be heard, and result in valuable insights into the needs and requirements of the technical community when it comes to decision-making. You can communicate with us through: - The MediaWiki talk page: https://www.mediawiki.org/wiki/Technical_decision_making/Technical_Decision… - Phabricator ticket: https://phabricator.wikimedia.org/T333235 - Core team mailing list: tdf-retro-2023(a)lists.wikimedia.org Thank you, Moriel, on behalf of the TDMP Retro Core Group Core group: - Moriel Schottlender (chair) - Daniel Kinzler - Chris Danis - Kosta Harlan - Temilola Adeleye On Thu, Mar 30, 2023 at 7:48 AM Tajh Taylor <ttaylor(a)wikimedia.org> wrote: > TLDR: The Foundation will be conducting a retrospective on the Technical > Decision Making Process. > > To the entire Wiki technical community, > > For quite some time now, we have experienced issues with the Technical > Decision Making Process (TDMP). Volunteer contributors and staff have asked > if we are still operating the Technical Decision Forum (TDF, the member > body that participates in the TDMP). Communication about it from the > Foundation has been inconsistent, and interest from the volunteer community > in joining has been low. Some of our most senior engineers on Foundation > staff have expressed that the process is flawed, doesn’t create room for > discussion about the technical issues surrounding a decision, and doesn’t > ensure participation by all stakeholders who may be affected by the > decision. Suffice it to say, the current state of affairs leaves many > participants wanting more. > > We must also remind ourselves of the purpose of a decision making > process. The decisions are not meant to be random or isolated. They > should be aligned to our technical strategy, and we should be able to look > at the decisions we have made and understand how they advance our progress > against that strategy. If the process is working as it should, the > decisions that are produced should represent settled wisdom, and not need > to be revisited too quickly. The goals for a well-run process include: > > - > > A straightforward, widely understood decision making process, that > - > > Facilitates impactful technical decisions to be made in a timely > manner, > - > > Incorporates input from staff and volunteers in our technical > community, with > - > > Decisions that align with accountability for decision outcomes, and > - > > Clear communication and transparent operations throughout the process. > > On examination of the contributing factors that have led us to this point, > the factor that stands out to me is the need for clear accountability: > accountability for the TDMP itself and accountability for each of the > decisions we make. Technical decision making, beyond a certain magnitude, > is a core organizational process for any engineering organization. It is > therefore important for us to examine and improve this process from time to > time to ensure organizational effectiveness. Not unrelated, regular > retrospectives are a routine agile software engineering practice to enact > continuous improvement. To keep our decision making process effective and > efficient, we need to conduct regular retros. Overall accountability for > maintaining an effective decision making process should rest with a person > who is sufficiently able to marshal resources and address problems at a > large scale – here at the Foundation, that resides in the executive level. > > The Foundation will be conducting a retro on the TDMP over the next couple > of months. Because we don’t yet have a habit of doing retros on this > process, and because there is a wide range of stakeholders we seek to hear > from, the process will be a bit more structured than an ordinary retro, and > will take more time. As we do more of these, we should get better at them. > The feedback gathered through the retro will be used to make changes to > improve the TDMP. > > Foundation staff will follow up with more information about the kickoff of > the retro and what steps will follow. I am looking forward to wide > participation in this retro. > > Here are the links to the relevant wiki page and Phab ticket: > > - Wiki page > <https://www.mediawiki.org/wiki/Technical_decision_making/Technical_Decision…> > - Phabricator ticket <https://phabricator.wikimedia.org/T333235> > > Thank you! And apologies for all the crossposting. > > Tajh Taylor (he/him/his) > > VP, Data Science & Engineering > > Wikimedia Foundation <https://wikimediafoundation.org/> > > -- Moriel Schottlender (she/her <https://pronoun.is/she>) Principal System Architect, Architecture Team <https://www.mediawiki.org/wiki/Wikimedia_Architecture_Team> Wikimedia Foundation https://wikimediafoundation.org/

1 0

Search Platform team - Weekly status updates
by Guillaume Lederrey 31 Mar '23

31 Mar '23

Hello all! The Search Platform team is again publishing weekly updates on wiki [1]. For example, if you want to know what we've been doing this week, have a look at [2]. Those updates are meant to be a bit more organized than trying to follow our Phabricator board [3], and try to highlight what might be interesting or significant for people outside of our team. They are still quite succinct and don't provide all the context around everything we do. In most cases, links are provided to phab tasks, or other relevant places where you can find more information. Please let us know if you find those updates useful! Or if you have further questions on our work. You can reach us on the talk pages, on the discovery mailing list [4], or join our office hours [5] Have fun! Guillaume [1] https://wikitech.wikimedia.org/wiki/Search_Platform/Weekly_Updates [2] https://wikitech.wikimedia.org/wiki/Search_Platform/Weekly_Updates/2023-03-… [3] https://phabricator.wikimedia.org/project/view/1227/ [4] https://lists.wikimedia.org/postorius/lists/discovery.lists.wikimedia.org/ [5] https://wikitech.wikimedia.org/wiki/Search_Platform/Contact#Office_Hours -- *Guillaume Lederrey* (he/him) Engineering Manager Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

Security and maintenance release: 1.35.10 / 1.38.6 / 1.39.3
by Sam Reed 30 Mar '23

30 Mar '23

1 0

Phabricator update window Thurs Mar 30 15:30 - 16:00 UTC (today)
by Brennen Bearnes 30 Mar '23

30 Mar '23

We're planning a brief window for Phabricator updates this (US) morning. I do not expect significant noticeable downtime, but a handful of requests are likely to error out during the restart. This update includes fixes for last week's UI changes, and one lingering patch from upstream. Phab task: https://phabricator.wikimedia.org/T333516 As usual, we'll track work on #wikimedia-operations. Thanks, -- Brennen Bearnes Release Engineering Wikimedia Foundation

1 0

[BREAKING CHANGE] Internet Explorer 11 will be JavaScript-less starting April 2023
by James Forrester 30 Mar '23

30 Mar '23

Hello all, Starting in April 2023, MediaWiki will end Grade A support for browsers that do not implement ES6 JavaScript.[0] This mostly affects the small number of Internet Explorer 11 users. A very small number of iOS users who have not upgraded to iOS 10 (released in 2017) are also affected. Users with these browsers will still be able to browse and contribute to the projects. Enhanced features will become unavailable. For example, the 2010 wikitext editor will not appear, scripts and gadgets will not operate, and notification buttons will take you to a page rather than open a pop-out. This change will affect fewer than 0.1% of page views to Wikimedia wikis. We previously raised the standard (from ES3 to ES5) in April 2017.[1] Providing JavaScript for IE 11 and other ES5 browsers adds a significant maintenance burden. It also hinders site speed for all users. Microsoft ended its official support for Internet Explorer 11 in June 2022,[2] and entirely removed it from Windows 10 in February 2023.[3] This change will land in the development branch used on all Wikimedia wikis this April, to be released as part of MediaWiki 1.41 around November 2023. Please help carry this message into your communities. (Tech News will announce this change as well.) For details about the JavaScript-less experience, see https://www.mediawiki.org/wiki/Special:MyLanguage/Compatibility#Browsers [0] https://caniuse.com/es6 listing browser support for ES6 [1] https://phabricator.wikimedia.org/T128115 [2] https://blogs.windows.com/windowsexperience/2021/05/19/the-future-of-intern… [3] https://techcommunity.microsoft.com/t5/windows-it-pro-blog/internet-explore… Yours, -- *James D. Forrester* (he/him <http://pronoun.is/he> or they/themself <http://pronoun.is/they/.../themself>) Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

Security pre-release announcement: 1.35.10 / 1.38.6 / 1.39.3
by Sam Reed 29 Mar '23

29 Mar '23

Hi all, On Thursday we will be issuing a security and maintenance release to all supported branches of MediaWiki. The new releases will be: - 1.35.10 - 1.38.6 - 1.39.3 This will resolve one issue in MediaWiki core, and two issues in bundled extensions along with bug fixes included for maintenance reasons. This includes various patches for PHP 8.0, PHP 8.1 and PHP 8.2 support. We will make the fixes available in the respective release branches (plus 1.40 which is currently in alpha candidate status) and master in git. Tarballs will be available for the above mentioned point releases as well. A summary of some of the security fixes that have gone into non-bundled MediaWiki extensions will also follow later. As a reminder, 1.38 is due to become end of life (EOL) in June 2023. 1.38.7 (due in June 2023 on the usual release cadence) is expected to be the last release for this branch. It is recommended to upgrade to 1.39 (the next LTS after 1.35). [1] https://www.mediawiki.org/wiki/Version_lifecycle

1 0

How to give a range block now?
by Bináris 29 Mar '23

29 Mar '23

Hi, I was surprised that the blocking interface followed others, and automatically and unchangeably fills the field with the user name or IP. Thus I cannot write a range after the IP any more. I captured a very small image with the problem, but it is not allowed here. Now, while range block for IPv4 anons is an everyday task, range block for IPv6 anons is compulsory every time. We give /64, otherwise it is senseless. By this time, I just wrote "/64" on the blocking interface after the IP. I don't know, when and why happened this change, but it makes blocking very tricky uncomfortable. What I can do, write /64 into the URL at the contributions of the vandal, but that is really not what I dreamt about. Can somebody explain, why this happened? Is there a way of range blocking that I am not aware of? Shall I ticket a bug? -- Bináris

2 2

Phabricator downtime (30 minutes) tomorrow between 14:00–16:00 UTC
by Tyler Cipriani 28 Mar '23

28 Mar '23

Hello *Phabricator will be down for 30 minutes tomorrow (Tue, 28 Mar 2023) between 14:00–16:00 UTC* due to network switch upgrades in its data center row[0]. Apologies for the inconvenience :( Tyler Cipriani (he/him) Engineering Manager, Release Engineering Wikimedia Foundation [0]: <https://phabricator.wikimedia.org/T330165>

2 1

Two new test base classes for extensions: ExtensionServicesTestBase and ExtensionJsonTestBase
by Lucas Werkmeister 27 Mar '23

27 Mar '23

Hi all, I wanted to quickly announce two new classes I added to MediaWiki core the other day: ExtensionServicesTestBase <https://gerrit.wikimedia.org/g/mediawiki/core/+/master/tests/phpunit/integr…> and ExtensionJsonTestBase <https://gerrit.wikimedia.org/g/mediawiki/core/+/master/tests/phpunit/integr…>. Both are abstract base classes for PHPUnit tests; by adding a test class extending one of these base classes, an extension can *opt into* additional tests, with very little extra code in the extension itself. If you don’t want to do that, nothing will change for you :) ExtensionServicesTestBase can be used to test “ExtensionServices” classes (e.g. CognateServices or WikibaseRepo). These classes are described on mw:Dependency Injection § Service registration in extensions <https://www.mediawiki.org/wiki/Dependency_Injection#Service_registration_in…>; basically, they’re a bunch of boilerplate code that makes an extension’s services in the service container easier to work with ( CognateServices::getStore() is equivalent to $services->getService( 'CognateStore' ), but the former can be autosuggested by the IDE and also has a known return type). An ExtensionServicesTestBase subclass tests that this boilerplate code looks like you’d expect it to: the methods are static, their name matches the service name, etc. Nothing exciting, but nice to have if you use this “ExtensionServices” pattern. ExtensionJsonTestBase is more exciting. The tests in this class read your extension.json, and try to create the various API modules, special pages, etc. that are specified in there, according to their factory specifications. This ensures, for instance, that the list of services specified in extension.json actually matches what the configured constructor or factory method expects (e.g. in case you added a service to the constructor and your unit test, but forgot to add it to extension.json), which might otherwise only be caught by browser tests (even integration tests don’t usually use the extension.json factories). More importantly, the tests also ensure that no HTTP or database connections are made when all these things are created. Services that make network requests as soon as they’re created, rather than only when they’re used, have been a performance issue in Wikibase in the past (T243729 <https://phabricator.wikimedia.org/T243729>), and these tests are meant to prevent such a thing from happening again. (In theory, all of this might work more or less well for skins as well as extensions. I have no reason to try that, since I don’t work on skins, but if you’re interested in it, feel free to experiment with it and see if it works out. I’ll point out that MediaWiki’s ExtensionJsonValidationTest, which “Validates all loaded extensions and skins using the ExtensionRegistry against the extension.json schema in the docs/ folder”, could be a precedent for an “ExtensionSomething” class actually covering both extensions and skins, so I don’t think the two new TestBase classes would necessarily need to be renamed.) A minimal example of using both of these tests in an extension might look like this: class EntitySchemaServicesTest extends ExtensionServicesTestBase { protected string $className = EntitySchemaServices::class; protected string $serviceNamePrefix = 'EntitySchema.'; } class EntitySchemaExtensionJsonTest extends ExtensionJsonTestBase { protected string $extensionJsonPath = __DIR__ . '/../../../../extension.json'; } Cheers, Lucas -- Lucas Werkmeister (he/er) Software Engineer Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30-577 11 62-0 https://wikimedia.de Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

1 0

About "Final view structure for view `page_view`"
by [[kgh]] 27 Mar '23

27 Mar '23

Hi, Does anybody know where this comes from, i.e., "view structure for view 'page_view'" (see below)? I was not able to find anything about this. Is this from MediaWiki core or from some extension I do not know about? Google suggests some Google Analytics-related stuff but ... Does not look like it to me. For context: Line 50013 prevents me from importing a database correctly. Thanks a lot for a pointer or some insight. Cheers, Karsten -- -- Final view structure for view `page_view` -- /*!50001 DROP VIEW IF EXISTS `page_view`*/; /*!50001 SET @saved_cs_client = @@character_set_client */; /*!50001 SET @saved_cs_results = @@character_set_results */; /*!50001 SET @saved_col_connection = @@collation_connection */; /*!50001 SET character_set_client = utf8 */; /*!50001 SET character_set_results = utf8 */; /*!50001 SET collation_connection = utf8_general_ci */; /*!50001 CREATE ALGORITHM=UNDEFINED */ /*!50013 DEFINER=`root`@`localhost` SQL SECURITY DEFINER */ /*!50001 VIEW `page_view` AS select `page`.`page_title` AS `page_title`,`page`.`page_counter` AS `page_counter` from `page` */; /*!50001 SET character_set_client = @saved_cs_client */; /*!50001 SET character_set_results = @saved_cs_results */; /*!50001 SET collation_connection = @saved_col_connection */; /*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */; /*!40101 SET SQL_MODE=@OLD_SQL_MODE */; /*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */; /*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */; /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */; /*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */; /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */; /*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l March 2023