Wikitech-l March 2019

wikitech-l@lists.wikimedia.org

94 participants
72 discussions

Discovery Weekly Update for the week starting 2019-03-18
by Chris Koerner 26 Mar '19

26 Mar '19

Hello, This is the weekly update from the Search Platform team for the week starting 2019-03-18. As always, feedback and questions are welcome. == Discussions == === Search === * Nearly done with the upgrade to ElasticSearch v6: ** Upgrade relforge to elasticsearch 6.5.4 [0] ** Upgrade deployment-elastic* to 6.5.4 [1] ** Build wmf-elasticsearch-search-plugins.deb that supports elastic 6.5.4 [2] * There was a minor bug in not getting a search result for "garrett marquis" or "Garrett Marquis"; Erik investigated and found it was a minor html issue and corrected it. FYI, it will take ~8 weeks for all content across all wikis to be reindexed. [3] * As part of the work done to separate the CirrusSearch/Elastic specific code from Wikibase code base, Stas deployed WikibaseCirrusSearch in production and all searches are now running through it [4] === WDQS === * New Release of Blazegraph (2.1.5) is announced. We have released 0.3.1 version of WDQS build with it. [5] [0] https://phabricator.wikimedia.org/T218116 [1] https://phabricator.wikimedia.org/T218247 [2] https://phabricator.wikimedia.org/T199791 [3] https://phabricator.wikimedia.org/T218001 [4] https://phabricator.wikimedia.org/T218715 [5] https://phabricator.wikimedia.org/T218746 ---- 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

1 0

GSOC 2019
by Adarsh Jaiswal 25 Mar '19

25 Mar '19

Hi everyone, I am Adarsh Jasiwal, currently in 1st year B. Tech. CSE and i want to contribute into your Wikimedia Foundation. I know the basics of web development and have done some projects based on it. If you could possibly tell me how could I be of any help I will be very Happy to help. Thanks , Regards, Adarsh Jaiswal.

2 1

Temporary personal break from mailing lists
by Pine W 24 Mar '19

24 Mar '19

Hi mailing list colleagues, I'm not sure whether I should make this be public, but I tend to be a frequent participant on mailing lists so maybe sharing this would be good. I am taking a temporary break from participating on Wikimedia mailing lists. Recently I am finding myself frequently experiencing frustration in conversations on lists, and I am concerned that in my frustration I may write something that I later regret. Also, I would like to be a generally positive presence on the lists, and I think that a "reset" would be good. I will remain in the Wikiverse for the foreseeable future. I like Wikimedia's educational mission, and I like my current principal project. I will continue to be a list subscriber, and may occasionally read list discussions. Also, I will continue to read off list emails. Perhaps in a month or two I will resume participating on lists. Thanks for all that you do in support of the mission. The Wikiverse is amazing and I am grateful to be a small part of it. Pine ( https://meta.wikimedia.org/wiki/User:Pine )

1 0

Where should extension default preferences be specified?
by Thomas Eugene Bishop 24 Mar '19

24 Mar '19

There are two places the default value for an extension-specific preference can be specified: (1) DefaultUserOptions in extension.json (2) onGetPreferences (or whatever function hooks GetPreferences) in MyExtension.hooks.php Which is better? If you do it in both places, and the defaults are in conflict, evidently onGetPreferences wins. This can be seen as follows: In extension.json add "DefaultUserOptions": { "BeSilly": false } In onGetPreferences add $preferences['BeSilly'] = array( 'type' => 'toggle', 'label' => 'Be silly', 'section' => "$sillySection", 'default' => true ); The result is that the checkbox is checked by default. If you omit the default from extension.json and include it only in onGetPreferences, the result is the same. It seems that using onGetPreferences is preferable, since the default can be combined there (encapsulated) with the other information about the preference, while putting the default in DefaultUserOptions separates it from the related information, a dependency to be avoided unless there’s some advantage I’m missing. Putting it in both places is at best redundant. However, the documentation in https://www.mediawiki.org/wiki/Manual:Hooks/GetPreferences appears to recommend $wgDefaultUserOptions or DefaultUserOptions. While it shows one example of specifying 'default' in onGetPreferences, it also shows an example in which 'default' is not specified in onGetPreferences. So what’s best? I don’t want to use onGetPreferences for the default if a future version of MediaWiki is going to turn that into a mistake. Also, does DefaultUserOptions serve any purpose, if onGetPreferences accomplishes the same thing better? Thanks in advance for any advice or clarification. Tom Wenlin Institute, Inc. SPC (a Social Purpose Corporation) 文林研究所社会目的公司 Software for Learning Chinese E-mail: wenlin(a)wenlin.com Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯

2 3

TechCom Radar 2019-03-20
by Kate Chapman 23 Mar '19

23 Mar '19

Hi All, Here are the minutes from this week's TechCom meeting: * IRC meeting RFC: Skin templating <https://phabricator.wikimedia.org/T217158> March 27 at 11pm PST (March 28 06:00 UTC, 07:00 CET) in #wikimedia-office * RFC Approved: RfC: Standards for external services in the Wikimedia infrastructure. <https://phabricator.wikimedia.org/T208524> * RFC Approved: The Great Namespaceization and Reorg <https://phabricator.wikimedia.org/T166010> * IRC Meeting hosted RFC: Add a frontend build step to skins/extensions to our deploy process <https://phabricator.wikimedia.org/T199004> * Minutes: <https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.20…> * Log: <https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.20…> * IRC Meeting hosted RFC: Let's stop using QUnit as a mechanism for integration tests <https://phabricator.wikimedia.org/T212521> ** Minutes: <https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.20…> ** Log: <https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.20…> You can also find our meeting minutes at <https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes> See also the TechCom RFC board <https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>. If you prefer you can subscribe to our newsletter here <https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar> Thanks, Kate -- Kate Chapman Senior Program Manager, Core Platform Wikimedia Foundation kchapman(a)wikimedia.org

1 0

Security Notification: A quick update on ongoing attempts to disrupt Wikimedia services
by David Sharpe 23 Mar '19

23 Mar '19

Hello, Over the past several days an individual has continued to attempt disruption of Wikimedia Services. The Wikimedia Foundation’s incident response processes are activated and countermeasures are in place. There have been a few times where brief service outages affecting Gerrit and Phabricator were necessary. We are working around the clock to safeguard all systems. We are putting a series of countermeasures and protections in place to limit the potential impact of similar activity going forward. We aren’t at liberty to provide more detail right now without putting our efforts at risk, but will update you again when we can. Please report any suspicious activity to security(a)wikimedia.org <mailto:security@wikimedia.org>. Thank you! Respectfully, David Sharpe Senior Information Security Analyst Wikimedia Foundation

2 1

Wikimedia production excellence (February 2019)
by Krinkle 23 Mar '19

23 Mar '19

📘 Read on Phabricator at https://phabricator.wikimedia.org/phame/live/1/post/141/ ------- How’d we do in our strive for operational excellence? Read on to find out! - Month in numbers. - Current problems. - Highlighted stories. ## 📊 *Month in numbers* * 7 documented incidents. [1] * 30 new Wikimedia-prod-error tasks created. [2] (17 new in Jan, and 18 in Dec.) * 27 Wikimedia-prod-error tasks closed. [3] (16 closed in Jan, and 20 in Dec.) There are in total 177 open Wikimedia-prod-error tasks today. (188 in Feb, 172 in Jan, and 165 in Dec.) ## 📉 *Current problems* There’s been an increase in how many application errors are reported each week. And, we’ve also managed to mostly keep up with those each week, so that’s great! But, it does appear that most weeks we accumulated one or two unresolved errors, which is starting to add up. I believe this is mainly because they were reported a day after the branch went out. That is, if the same issues had been reported 24 hours earlier in a given week, then they might’ve blocked the train as a regression. → https://phabricator.wikimedia.org/tag/wikimedia-production-error/ Below is breakdown of unresolved prod errors since last quarter. (I’ve omitted the last three weeks.) By month: - February: 5 reports (1.33-wmf.16, 1.33-wmf.17, 1.33-wmf.18). - January: 3 reports (1.33-wmf.13, 1.33-wmf.14). - December 2018: 5 reports (1.33-wmf.9). - November 2018: 3 reports (1.33-wmf.2). - October 2018: 1 report (1.32-wmf.26). - September 2018: 2 reports (1.32-wmf.20). By steward and software component: Core Platform: * Parser: https://phabricator.wikimedia.org/T216664. * Revision backend: https://phabricator.wikimedia.org/T214035, https://phabricator.wikimedia.org/T212428. Growth: * Echo: https://phabricator.wikimedia.org/T217079. * Flow: https://phabricator.wikimedia.org/T212742, https://phabricator.wikimedia.org/T204793. * Page deletion: https://phabricator.wikimedia.org/T203913. Wikidata: * Wikibase: https://phabricator.wikimedia.org/T217329, https://phabricator.wikimedia.org/T215380, https://phabricator.wikimedia.org/T213483. * WikibaseLexeme: https://phabricator.wikimedia.org/T207479, https://phabricator.wikimedia.org/T200906. * WikibaseQualityConstraints: https://phabricator.wikimedia.org/T212282. Performance: * Lib-rdmbs: https://phabricator.wikimedia.org/T212284. Multimedia: * MediaWiki uploading: https://phabricator.wikimedia.org/T208539. Fundraising-Tech: * CentralNotice: https://phabricator.wikimedia.org/T209741. (Nobody - pending code ownership process): * ImageMap extension: https://phabricator.wikimedia.org/T217087. * Nuke extension: https://phabricator.wikimedia.org/T212690. ## *️⃣ *Fixed exposed fatal error on Special:Contributions* Previously, a link to Special:Contributions could pass invalid options to a part of MediaWiki that doesn’t allow invalid options. Why would anything allow invalid options? Let’s find out. Think about software as an onion. Software tends to have an outer layer where everything is allowed. If this layer finds illegal user input, it has to respond somehow. For example, by informing the user. In this outer layer, illegal input is not a problem in the software. It is a normal thing to see as we interact with the user. This outer layer responds directly to a user, is translated, and can do things like “view recent changes”, “view user contributions” or “rename a page”. Internally, such action is divided into many smaller tasks (or functions). For example, a function might be “get talk namespace for given subject namespace”. This would answer “Talk:” to “(Article)”, and “Wikipedia_talk:” to “Wikipedia:”. When searching for edits on My Contributions with “Associated namespaces” ticked, this function is used. It is also used by Move Page if renaming a page together with its talk page. And it’s used on Recent Changes and View History, for all those little “talk” links next to each page title and username. If one of your edits is for a page that has no discussion namespace, what should MediaWiki do? Show no edits? Skip that edit and tell the user “1 edit was hidden”? Show normally, but without a talk link? That decision is made by the outer layer for a feature, when it catches the internal exception. Alternatively, it can sometimes avoid an exception by asking a different question first – a question that cannot fail. Such as “Does namespace X have a talk space?”, instead of “What is the talk space for X?”. When a program doesn’t catch or avoid an exception, a fatal error occurs. Thanks to D3r1ck01 for fixing this fatal error. – https://phabricator.wikimedia.org/T150324 💡*ProTip*: If the Jenkins build is failing for a project and you suspect it’s unrelated to the project itself, be sure to report it to Phabricator under “Shared Build Failure”, or use https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?project=share… . ## 🎉 *Thanks!* Thank you to everyone who has helped by reporting, investigating, or resolving problems in Wikimedia production. Including: Aaron Schulz, Addshore, Alaa Sarhan, Amorymeltzer, Anomie, D3r1ck01, Daimona, Daniel Kinzler, Hashar, Hoo man, Jcrespo, KaMan, Mainframe98, Marostegui, Matej Suchanek, Ottomata, Pchelolo, Reedy, Revi, Smalyshev, Tarrow, Tgr, Thcipriani, Umherirrender, and Volker E. Thanks! Until next time, – Timo Tijhof 🍏 *He got me invested in some kind of.. fruit company.* ------- Footnotes: [1] Incidents. – https://wikitech.wikimedia.org/wiki/Special:AllPages?from=Incident+document… [2] Tasks created. – https://phabricator.wikimedia.org/maniphest/query/a0yuo6bqDOrh/#R [3] Tasks closed. – https://phabricator.wikimedia.org/maniphest/query/7pmQcTvTWw_4/#R

2 1

OOUI question
by Huji Lee 22 Mar '19

22 Mar '19

Hi everyone! I am pretty sure I am missing something obvious here, but I cannot spot it and I would appreciate a fresh set of eyes looking at it. The script at https://fa.wikipedia.org/wiki/User:Huji/UserMessages.js is the backbone of a OOUI-based tool. I have made quite a few of a these tools in the past with no problem. For now, this tool is only supposed to do two things: add a link to the "More" dropdown on the top of the page (only if it is a user talk page), and open a OOUI dialog once the link is clicked. The first part works and I have verified that the *createWindow* method is called when you click the link, but the dialog is not shown. Can someone kindly look at my code and tell me what I am missing? Thanks, Huji

2 4

[Development Metrics] Github Git activity indexed on wikimedia.biterg.io
by Andre Klapper 21 Mar '19

21 Mar '19

For those who like statistics: I've made https://wikimedia.biterg.io index the Git activity in nearly all Wikimedia Github repositories which are canonical on Github (means: not mirrored from Wikimedia Git/Gerrit) and are not upstream forks. The six exceptions not indexed are repositories which I could not sort out due to confusing differences in commit logs: * https://github.com/wikimedia/mediawiki-services-eventstreams vs https://gerrit.wikimedia.org/g/mediawiki/services/eventstreams * https://github.com/wikimedia/jmx_exporter vs https://gerrit.wikimedia.org/g/operations/debs/prometheus-jmx-exporter * https://github.com/wikimedia/webpagetest vs https://gerrit.wikimedia.org/g/performance/WebPageTest * https://github.com/wikimedia/operations-debs-python-confluent-kafka vs https://gerrit.wikimedia.org/g/operations/debs/python-confluent-kafka * https://github.com/wikimedia/operations-debs-mcrouter vs https://gerrit.wikimedia.org/g/operations/debs/mcrouter * https://github.com/wikimedia/cassandra-metrics-collector vs https://gerrit.wikimedia.org/g/operations/software/cassandra-metrics-collec… Note that is about Git activity only. This is not (yet) about data on PRs and issues on Github (see. For more info, see https://www.mediawiki.org/wiki/Community_metrics Cheers, andre -- Andre Klapper | Bugwrangler / Developer Advocate https://blogs.gnome.org/aklapper/

1 0

Comments and questions regarding VisualEditor, Citoid, and Parsoid
by Pine W 21 Mar '19

21 Mar '19

I'd like to say thanks to the folks who have been working on VisualEditor, Citoid, and Parsoid in the past few years. When I first started to work in 2015 on what I eventually called the LearnWiki project <https://meta.wikimedia.org/wiki/Grants:IEG/Motivational_and_educational_vid…>, I was a bit hesitant to recommend VisualEditor due to it having some rough spots in performance and reliability, but I knew that VE was probably the way of the future for new Wikipedia contributors. As I've been writing scripts recently for a 2019 small pilot project that will teach users how to create citations with VE <https://meta.wikimedia.org/wiki/Grants:Project/Rapid/Pine/Continuation_of_e…>, I've been impressed by how much has improved. The VE's performance seems to be faster, the automatic citation tool can be easy and enjoyable to use, and the system (VE + Parsoid + Citoid) seems to be generally stable on ENWP. I think that you made the desktop user experience significantly better for new contributors on ENWP who use VE. While I'm writing, I'll ask a couple of related questions. If someone knows of recent research that analyzes the productivity and longevity of new users who try the VE and/or New Wikitext Editor ("NEWT") interfaces, I would be appreciative if that information could be added to this project talk page <https://meta.wikimedia.org/wiki/Grants_talk:Project/Rapid/Pine/Continuation…> so that I can take a look. Especially interesting would be research that shows points in workflows on English Wikipedia where new editors who use VE seem to become stuck. (The sticking points may have more to do with policies than with interfaces.) Also, Guy Macon has asked some questions here (a secton of the same talk page) <https://meta.wikimedia.org/wiki/Grants_talk:Project/Rapid/Pine/Continuation…> regarding the percentage of editors that use different editing interfaces. Please participate on the talk page if you have the time and interest. Thanks again for the good work on VisualEditor and related systems. Pine ( https://meta.wikimedia.org/wiki/User:Pine )

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