Wikitech-l February 2019

wikitech-l@lists.wikimedia.org

56 participants
63 discussions

Your Participation Requested - Interview about your local development environment
by Jeena Huneidi 08 Feb '19

08 Feb '19

Hello Everyone, I am working on improving developer productivity! Specifically, I am aiming to improve the local development environment. Satisfaction with the local development environment got the second lowest score in the developer satisfaction survey, and we (Release Engineering) would like to find out which things about it you like, and which are troublesome. In order to do so, we need your help! I’d love to have the opportunity to interview you about your local setup and/or observe how you interact with it. Please send me an email if you’d like to participate, and I or one of my colleagues will schedule some time with you. I’m looking forward to our conversations. This is a chance for you to shape the local development environment, so please don’t hold back :) Outcomes resulting from the interviews (non personally identifiable information) will be made available after analysis has been completed. -- Jeena Huneidi Software Engineer, Release Engineering Wikimedia Foundation

2 4

2019-02-06 Scrum of Scrums meeting notes
by Grace Gellerman 06 Feb '19

06 Feb '19

https://www.mediawiki.org/wiki/Scrum_of_scrums/2019-02-06 =2019-02-06= == Callouts == * Fundraising campaigns https://meta.wikimedia.org/wiki/CentralNotice/Calendar == Audiences == === Contributors === ==== Community Tech ==== * Blocked by: * Blocking: * Updates: ** ==== Anti-Harassment Tools ==== * Blocked by: * Blocking: * Updates: ** ==== Editing ==== * Blocked by: * Blocking: ** Updates: ** ==== Growth ==== * Blocked by: * Blocking: * Updates: ** ==== Language ==== * Blocked by: * Blocking: * Updates: ** === Readers === ==== iOS native app ==== * Blocked by: * Blocking: * Updates: **Finishing up 6.2 ( https://phabricator.wikimedia.org/tag/ios-app-v6.2-beluga-on-a-pogo-stick/), release that contains editing & syntax highlighting. Should be wrapped up this week. ==== Android native app ==== * Blocked by: * Blocking: * Updates: ** ==== Readers Web ==== * Blocked by: * Blocking: * Updates: ** Summary: the team is back from All Hands, MobileFrontend Webpackification is complete, upcoming MobileFrontend Architecture work is being planned, and we're continuing the Advanced Mobile Contributions project. ** Responsive website (MinervaNeue / MobileFrontend): *** Advanced mobile contributions https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions **** Design updates to Settings page & opt-in toggle T214195 **** Add informational links to opt-in toggle T214180 **** Page/talk toggle v1 T212216 **** Build opt-in toggle T211197 *** Invest in the MobileFrontend & MinervaNeue frontend architecture https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFro… **** Webpackify editing T213340 (MobileFrontend is now Webpack'd!!!) **** Enable Babel transpiling in MobileFrontend T202746 **** Separate lazy loading from Skin T214658 **** Migrate deprecated calls T208915 *** Page issues https://www.mediawiki.org/wiki/Reading/Web/Projects/Mobile_Page_Issues **** Miscellaneous bug fixes and maintenance T212376 T212371 *** ExternalGuidance extension review and support *** Miscellaneous bug fixes and maintenance T213336 T202374 T214955 T211724 ** Desktop website (Vector, Popups) *** Popups https://www.mediawiki.org/wiki/Page_Previews **** WMDE reference previews review and support T67114 https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/ReferencePreviews **** Miscellaneous bug fixes and maintenance T214974 ** PDF rendering (Proton) https://www.mediawiki.org/wiki/Reading/Web/PDF_Functionality *** Remaining work tracked in deploy Proton T181084 ==== Readers Infrastructure ==== * Blocked by: ** need guidance from SRE / Service Ops on how to handle system package / npm package version sync for Proton: https://phabricator.wikimedia.org/T213366#4906913 ** could use some info from SRE / Traffic on how Varnish interacts with Proton https://phabricator.wikimedia.org/T213371#4908036 (not urgent) * Blocking: * Updates: ** RfC on best method for incorporating PCS data into page HTML: https://phabricator.wikimedia.org/T213505 - looking for feedback from SRE / Service Ops mainly ** App Editor Tasks work in progress ==== Multimedia ==== * Updates ** ==== Parsing ==== * Blocked by: * Blocking: * Updates: ==== UI Standardization ==== * Blocked by: * Blocking: * Updates: ** == Technology == === Analytics === * Blocked by: * Blocking: * Updates: ** === Cloud Services === * Blocked by: * Blocking: * Updates: ** === Fundraising Tech === * Blocked by: * Blocking: * Updates: ** Looking at possibility of recurring upsell - i.e. asking donors if they want to recur after a successful one-time donation ** Civi version upgrade ** Still making tweaks for Payments-wiki PHP and mediawiki upgrade ** Starting work on decoupling last link between payments-wiki frontend and civi db backend ** Working on reducing volume of TY emails for monthly donors === MediaWiki Core Platform === * Blocked by: * Blocking: * Updates: ** Last week: ALL HANDS === Performance === * Blocked by: ** * Blocking: ** * Updates: ** runbooks: Grafana best practices (initial version). https://wikitech.wikimedia.org/wiki/Performance/Runbook/Grafana_best_practi… ** Assisted RelEng w/migrating various repos' Jenkins tests from node6 to node10 (in progress) https://phabricator.wikimedia.org/T211784 ** Continued work on registry cleanup sprint https://phabricator.wikimedia.org/T202154 ** Initial performance review of Extension:ExternalGuidance https://phabricator.wikimedia.org/T214170 ** Patch to make addWiki.php easier to re-run in case of certain DBs having problems https://gerrit.wikimedia.org/r/486406 === Release Engineering === * Blocked by: ** * Blocking: ** * Updates: ** Train Health: *** Last week: No train, WMF ALL HANDS! *** This week: 1.33.0-wmf.16 - https://phabricator.wikimedia.org/T206670 - no problemo *** Next week: 1.33.0-wmf.17 - https://phabricator.wikimedia.org/T206671 === Research === * Blocked by: * Blocking: * Updates: === Scoring Platform === * Blocked by: * Blocking: * Updates: === Search Platform === * Blocked by: * Blocking: * Updates: ** === Security === * Blocked by: * Blocking: * Updates: **Last week allhands === Services === * Blocked by: * Blocking: * Updates: ** === Site Reliability Engineering === * Blocked by: ** None * Blocking: ** None * Updates: ** Slow week after allhands, no updates == Wikidata == * Blocked by: * Blocking: * Updates: ** == German Technical Wishlist == * Blocked by: * Blocking: * Updates: ** == Multi-Content Revisions == * Blocked by: * Blocking: * Updates: ** == SoS Meeting Bookkeeping == * Updates: **

1 0

New dumps mirror: The Free Mirror Project
by Ariel Glenn WMF 06 Feb '19

06 Feb '19

I am happy to announce a new mirror site, located in Canada, which is hosting the last two good dumps of all projects. Please welcome and put to good use https://dumps.wikimedia.freemirror.org/ ! I want to thank Adam for volunteering bandwidth and space and for getting everything set up. More information about the project can be found at http://freemirror.org/ Enjoy! Ariel

1 0

MediaWiki-CodeSniffer 24.0.0 released
by Kunal Mehta 06 Feb '19

06 Feb '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello! MediaWiki-CodeSniffer 24.0.0 is now available for use in your MediaWiki extensions and other projects. This release features new sniffs, an upstream update, and other bug fixes. The 19.x branch for PHP 5.5 codebases also saw another release, 19.2.0, which just disabled the problematic Generic.PHP.DeprecatedFunctions sniff. Here's the changelog for 24.0.0: * Whitelist @after and @before phpunit annotations (Umherirrender) * Update PHP_CodeSniffer to 3.4.0 (Kunal Mehta) * Enable new Generic.VersionControl.GitMergeConflict sniff (Kunal Mehta) * Copyedit comments (Max Semenik) * Exclude methods in anonymous classes from the nested_functions sniff (mainframe98) * Disallow use of @access (Umherirrender) * Add $wgLang and $wgOut to ExtendClassUsageSniff (Umherirrender) * Enable Generic.WhiteSpace.IncrementDecrementSpacing (Umherirrender) * Enable Generic.Formatting.SpaceAfterNot with spacing 0 (Umherirrender) * Require mbstring since it is needed for FunctionAnnotationsSniff (Mark A. Hershberger) * Enable Generic.CodeAnalysis.EmptyPHPStatement (Umherirrender) * Fix UnusedUseStatementSniff to find more unused statements (Umherirrender) * Remove ForLoopWithTestFunctionCall (Tim Starling) * Add a sniff to replace !! with a cast to boolean (mainframe98) * Adjust warning text for PhpunitAnnotations.NotClassTrait sniff (Umherirrender) * Expand ExtendClassUsageSniff to check for config globals (Umherirrende r) * Also exclude anonymous classes in AssignmentInReturnSniff (mainframe98 ) * Replace sniff for forbidden globals by deprecated globals (Umherirrender) Special shout out to mainframe98 as our newest contributor! Thanks, - -- Legoktm -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAlxamTUACgkQ8QX4EBsF JpulOA/8DpnvhpG5/ddbgbfE7EIzM+iBHA8X5s7B+/FIdRBdcIFknJZHd/wdOSHi oitHSMmUxZW06smgfw/YAI+0gJCLdqzytJyJXY4CKVesNl+oQ7S9SH505aEhu60j +pfti6xwxQfRdSItighxmcLj/9IDAQCYC3rYJCpTOlf9Zwn55ePP6VD+8mmvUKjk G8OGtjHhSemuVEQIRrqpJo85HZHAMPHrBZ1u0WFunps2YY7WkCio5Y+Xc82Qz6vV CbSOO/52YVEMFhWSW+Qz/MczquAP5TlM9dur5yDULiX+Ma5PfshLiYuQ2UOI+1lS AsNZ+e9dZt/gDu39BwyMEBHg4D3SzwSo+0K5N+a+zT+ldt0qDzeEC32t3Bi5Lt/d GP70JQs7nl/2aox+xJrBz+4SJoI00LogSi2YF02xueh5Gp3I4yjkeS+gRe9leeV2 iDZx0JqSzLJbZDzL03MgenpZPioHn9N8BamXDbD3K2lK8kY8TueefAsx3/W7L55x P4GNY7wtahrpcco65zrNO0BcRgVwXn+HtreouKzd1P3D4isOUrGbfNIkV0UCPtht DUxRi49sW4FH7ftHo9AJQLQb11CIEGLT0fffIjxzcv/2kJz7CKBwS4bbskqMZt8H Ov4IgrXFcWEJZpcC2xKNOYmHZ0aGnQ4kvyoBvR53PfpdxKg6SAk= =Sf7F -----END PGP SIGNATURE-----

1 0

Sunsetting VP8 version of WebM for video playback
by Brion Vibber 05 Feb '19

05 Feb '19

A few months ago I switched our TimedMediaHandler's config to support the newer, more bandwidth-efficient VP9/Opus variant of WebM and to use these preferably over the older VP8/Vorbis version when creating scaled, playback-ready derivatives. (This does not affect upload support -- you may continue to upload video files in WebM VP9, WebM VP8, or Ogg Theora formats, with either Vorbis or Opus audio.) Conversions of existing files on Commons ran in the background for some weeks, finishing in November. I'm now running a final pass for high-resolution files and any files on other wikis that didn't get a conversion yet, in preparation for removing the VP8 derivatives in the next couple of weeks to free storage space. This should have relatively little visible effect for users, unless someone is relying on the particular derivative files with extensions like ".360p.webm"; the new versions are named like ".360p.vp9.webm". Note that IE 11 users using the "WebM Media Foundation Components for IE <https://www.webmproject.org/ie/>" will not be able to play back the new VP9/Opus files natively, as this driver has never been updated for VP9 or Opus. IE 11 users will receive low-resolution, slow JavaScript-based video playback instead. If you find this is troublesome, the recommended solution is to switch to any other browser. Third-party MediaWiki + TimedMediaHandler users should be aware that the defaults are changing, and in future the VP8-specific support and code paths may be removed. TimedMediaHandler will probably change a lot in the coming months with upcoming WebVTT subtitle format, a streamlined videojs-based player, and hopefully more! -- brion

2 2

The mw.ext construct in lua modules
by John Erling Blad 05 Feb '19

05 Feb '19

At the Extension:Scribunto/Lua reference manual, at several places,[1] it is pointed out that the lua-libs should use the form 'mw.ext.NAME'. This creates visual noise in the code. Any lib included should have a extension page, thus it has already been given an unique name. In addition, only the libraries that need to be preloaded are added to the mw-structure, and those are the extensions. The ext-addition is like saying "this is an extension and it is only extensions that needs to be added to the mw-struct so we make it abundantly clear that this is an extension". The only cases where a name can collide is if some external lib is included, that external lib has the same name as an extension, and if someone in addition preloads the external lib. The chance is quite frankly pretty slim, as there are rather few external libs that makes sense to preload in this environment, especially as preloading imply some kind of interaction with the environment. That means it is an extension. I guess I'm stepping on some toes here… So to make it abundantly clear, not 'mw.ext.NAME' (or 'mw.ext.NaMe', or 'mw.ext.name') but 'mw.name' (lowercase, not camelcase). If the call is a constructor or some kind of builder interface, then 'mw.name(…)' is totally valid. I do not believe it is wise to turn the lib into an instance by the call, but it can return an instance, it can cache previously returned instances, and it can somehow install the instance(s) in the current environment. An extension should have any pure root libs at 'pure/name.lua' and additional libs at 'pure/name/additional.lua', where 'pure' is resolved in the 'ScribuntoExternalLibraries' hook. [1] https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Ext…

6 13

Upcoming Search Platform Office Hours—February 6th
by Trey Jones 05 Feb '19

05 Feb '19

The Search Platform Team <https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds office hours the first Wednesday of each month—that's tomorrow! Come ask us anything about Wikimedia search! We’re particularly interested in: * Opportunities for collaboration—internally or externally to the Wikimedia Foundation * Challenges you have with on-wiki search, in any of the languages we support But we're happy to talk about anything search-related. Feel free to add your items to the Etherpad Agenda for the next meeting. Details for our next meeting: Date: Wednesday, February 6th, 2018 Time: 16:00-17:00 GMT / 08:00-9:00 PST / 11:00-12:00 EST / 17:00-18:00 CET Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours Google Meet link: https://meet.google.com/vyc-jvgq-dww *N.B.:* Google Meet System Requirements <https://support.google.com/meet/answer/7317473> Trey Jones Sr. Software Engineer, Search Platform Wikimedia Foundation

1 0

Discovery Weekly Update for the week starting 2019-01-21
by Chris Koerner 05 Feb '19

05 Feb '19

Hello, This is the weekly update from the Search Platform team for the week starting 2019-01-21 (acknowledging a little delay). As always, feedback and questions welcome. == Discussions == === Search === * Trey did a write up about his ideas for the wrong keyboard implementation and UI, and the new language models and parameter optimization for TextCat for the wrong-keyboard and wrong-encoding detection. [0] * Trey also reviewed, updated and manually re-built the Hebmorph plugin for ElasticSearch 6 with help from the rest of the Search team [1] * David double checked that chi to psi/omega indices are no longer used and delete them. [2] * David also worked on dropping the "archive" type in the general index [3] * David wrapped up on moving the phrase suggest related code to its FallbackMethod [4] * Erik worked on modifying Wikidata entity completion search for per-language tuning parameters [5] * Erik also worked on a bug where we didn't retain cross-cluster identifier in OtherIndexes [6] * Erik fulfilled a feature request to add chronological sorting by-page-creation-timestamp for search results [7] * David also upgraded the Elasticsearch plugins extra, extra-analysis and highlighter to elasticsearch 6.5.4 [8] * Stas is working on separating ElasticSearch parts of Wikibase into a separate extension [9] [0] [https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Implementation_Desig… [1] https://phabricator.wikimedia.org/T214439 [2] https://phabricator.wikimedia.org/T214052 [3] https://phabricator.wikimedia.org/T200198 [4] https://phabricator.wikimedia.org/T213098 [5] https://phabricator.wikimedia.org/T213106 [6] https://phabricator.wikimedia.org/T214050 [7] https://phabricator.wikimedia.org/T195071 [8] https://phabricator.wikimedia.org/T214312 [9] https://phabricator.wikimedia.org/T190022 ---- Subscribe to receive on-wiki (or opt-in email) notifications of the Discovery weekly update. https://www.mediawiki.org/wiki/Newsletter:Discovery_Weekly The archive of all past updates can be found on MediaWiki.org: https://www.mediawiki.org/wiki/Discovery/Status_updates Interested in getting involved? See tasks marked as "Easy" or "Volunteer needed" in Phabricator. [1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R [2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R Yours, Chris Koerner (he/him) Community Relations Specialist Wikimedia Foundation

2 1

Re: [Wikitech-l] Changes to the Block paradigm
by 80hnhtv4agou＠bk.ru 04 Feb '19

04 Feb '19

what about abuse by administrators and stewards ? From: Moriel Schottlender Sent: Monday, January 7, 2019 7:53 PM To: Wikimedia developers ; Wikitech-ambassadors(a)lists.wikimedia.org Subject: [Wikitech-l] Changes to the Block paradigm Greetings, Have you written code that deals with or depends on user blocks? Read on. = TL;DR: = The new “Partial Blocks” feature has fundamentally changed the way MediaWiki considers what “block” means; any code that handles blocks should consider whether the questions it is asking are still valid or should adjust its expectations. Please read for more details. = Preamble = A couple of months ago, as part of the Anti Harassment Tools team’s continued work on improving the general experience of our users and providing more robust tools to administrators, an RFC to enable “Partial Blocks[1]” has passed and has been implemented in MediaWiki, affecting the way blocking users operates. While the actual feature, enabling the blocking of users for specific pages and namespaces, will be slowly rolled out as part of our rollout and testing plans, the change has resulted in a complete change of paradigm for what “block” means throughout our code. = Change of paradigm = Until recently, Block was fairly straight forward; whether a block was done on an IP range or a specific user, the question the code would ask is “is the user blocked from this action” and the answer will be a boolean yes or no, depending on whether the user was blocked from the wiki and whether the action was a blockable action. With the new Partial Blocks feature, that question is now more elaborate. We are giving admins and wikis in general much more robust options when deciding to block IPs or users. “Sitewide” block is no longer the only option. Now, a user can be blocked from editing a specific page, and soon from a specific namespace. There are also blocks that prevent a specific action, such as uploading files or creating new pages. This means that the question “is the user blocked” is no longer accurate. In most cases, the question should be “is the user blocked from the action on this page”, because users may receive a block that is not sitewide, but from a specific page or set of pages. = What we worked on = The Anti Harassment Tools team has been working diligently on making sure that the new blocking behavior does not produce obvious regressions in production, and does not add to any still existing inconsistencies. In cases where we identified a clear mismatch, we’ve tried to either fix it outright or alert the code owners to adjust. If we have missed any iteration or use-case, please open a Phabricator ticket and add the ‘anti-harassment’[2] tag to it. If the use-case is sensitive or identifies a current loop-hole in the way blocks work, please make it a security ticket and alert us and the relevant team immediately. = General steps forward = While the team is following up on making the code clear and robust and fixing what we’ve identified as paradigm-changes to deal with, there are still many instances where the changes required to the code are not straight-forward or clear. Some extensions ask whether a user is blocked and may need to change the way that the product’s “business logic” behaves. These are cases where we cannot make the decision for the codebase. We encourage you to look at your product and consider adjusting if necessary. = General guidance = We’ve identified some areas that may help code owners adjust their products to properly take advantage of the new feature and adjust to the new paradigm change. This list is not exhaustive, but may help you spot areas in your code that can easily be changed: * User::isBlocked() has changed its meaning, and its use cases should be re-examined depending on what your code intends to check. For the most part, if there’s a Title object available, User::isBlockedFrom() is a good option. Otherwise, consider using User::getBlock() and Block::isSitewide() * Block::prevents( ‘edit’ ) is an operation that doesn’t make sense anymore, because a block on the ‘edit’ action now depends on context (the title). * Determining whether a block prevents a user from editing their own user talk page has changed. For a sitewide block, if the $wgBlockAllowsUTEdit config is false, then the block prevents the user editing their user talk page, but if it is true, then whether they can edit their user talk page depends on the ipb_allow_usertalk flag on the block. For a partial block to a page or pages, these flags are not taken into account: if the user’s talk page is specified as a blocked page, then they cannot edit their user talk page; if it is not, then they can edit it. Block::prevents( ‘editownuserpage’ ) should therefore not be checked for a partial page block[3]. We plan to deprecate that parameter officially, please consider if this affects your code. * Please check that any classes that extend Action or FormSpecialPage return the correct value for requiresUnblock(). To summarize, in general, the meaning of asking whether a block exists has changed, and any code piece that needs this information should adjust itself to account for partial blocks, depending on its goals. Thank you, Moriel, on behalf of the Anti Harassment Tools Team References: [1] Partial blocks: https://meta.wikimedia.org/wiki/Community_health_initiative/Per-user_page,_… [2] Anti Harassment tools board: https://phabricator.wikimedia.org/project/view/2660/ [3] For a discussion of this, see: https://phabricator.wikimedia.org/T210475 -- Moriel Schottlender (she/her) Senior Software Engineer, Tech Lead Community Tech and Anti Harassment Tools @mooeypoo (IRC / Phabricator) _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

2 1

Wednesday: Technical Advice IRC Meeting
by Michael Schönitzer 04 Feb '19

04 Feb '19

Reminder: Technical Advice IRC meeting this week **(Wednesday) 4-5 pm UTC** on #wikimedia-tech. Question can be asked in English & German. The Technical Advice IRC Meeting is a weekly support event for volunteer developers. Every Wednesday, two full-time developers are available to help you with all your questions about Mediawiki, gadgets, tools and more! This can be anything from "how to get started" over "who would be the best contact for X" to specific questions on your project. If you know already what you would like to discuss or ask, please add your topic to the next meeting: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting Hope to see you there! Michi (for the Technical Advice IRC Meeting crew) -- Michael F. Schönitzer Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Tel. (030) 219 158 26-0 https://wikimedia.de Unsere Vision ist eine Welt, in der alle Menschen am Wissens der Menschheit teilhaben, es nutzen und mehren können. Helfen Sie uns dabei! 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

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 February 2019