Hi Everyone,
It's time for Wikimedia Tech Talks 2019 Episode 8! This talk will take
place 25, Sept, 2019 at 6PM UTC.
*Topic:* How to compare text across multiple languages
*Speaker:* Diego Saez-Trumper, Research Scientist
*Summary:*
This talk will explain how cross-lingual word embeddings works, and how
they can be used to measure the semantic distance between words and
documents across different languages. It will cover some use cases in our
section and template alignment work.
The link to the Youtube Livestream can be found here:
https://www.youtube.com/watch?v=eaDc_4-TNos
During the live talk, you are invited to join the discussion on IRC at
#wikimedia-office
You can watch past Tech Talks here:
https://www.mediawiki.org/wiki/Tech_talks
If you are interested in giving your own tech talk, you can learn more
here:
https://www.mediawiki.org/wiki/Project:Calendar/How_to_schedule_an_event#Te…
Many kindnesses,
Sarah R. Rodlund
Technical Writer, Developer Advocacy
<https://meta.wikimedia.org/wiki/Developer_Advocacy>
srodlund(a)wikimedia.org
Hi,
for HTML version, see
https://www.mediawiki.org/wiki/Scrum_of_scrums/2019-09-25
Since I have received one positive piece of feedback on my link shortening
experiment, and no negative feedback, this week's meeting notes have short
links. You can see what was shortened here:
https://www.mediawiki.org/w/index.php?diff=3427791&oldid=3427790&title=Scru…
I'm still open to feedback. :)
Željko
--
= 2019-09-25 =
== Callouts ==
* SRE DBAs point out that S4 primary database master switchover scheduled
for Thursday 26th at 05:00 AM UTC (read-only required) [[phab:T230784]]
* Release Engineering: REMINDER: We're at 1.34.0-wmf.24 this week. The last
branch for this release will be wmf.25 on 30 September. Teams who want to
ship things for MW 1.34 should land them now. (If you do not mark code as
deprecated in the next few days, you have to maintain it for another nine
months.)
* UI Standardization: Special:Contributions got switched to OOUI and in the
course improved user-experience and made it mobile ready (AMC work
related). Feedback welcome [[phab:T117736]]
== Product ==
=== Editing ===
* Updates:
** ApiVisualEditorEdit: Remove special handling for SpamBlacklist (task
[[phab:T211443]])
** Add new EditAttemptStep stage: firstChange (task [[phab:T229079]])
** Add unit tests for read-mode reference filter (task [[phab:T150418]])
** Use MW import rules in MW tests (task [[phab:T150418]])
** Add another looser selector for catching pasted references (task
[[phab:T232461]])
=== Growth ===
* Updates:
** WelcomeSurvey: Remove "topics" question (task [[phab:T232400]])
** WelcomeSurvey: Add/change answer options for "reason" question (task
[[phab:T232400]])
** WelcomeSurvey: Remove multiselect infusion code (task [[phab:T232400]])
** Remove popup version of WelcomeSurvey (task [[phab:T233198]])
** Remove GEHelpPanelSearchEnabled feature flag (task [[phab:T233283]])
** WelcomeSurvey: Fix saving results when group is overridden (task
[[phab:T233263]])
=== iOS native app ===
* Updates:'
** 6.5 in development
*** History & diffs - beginning development against prototype endpoints
https://phabricator.wikimedia.org/tag/ios-app-v6.5/
**** Wrapping up wikidiff2 PR [[gerrit:534897]]
=== Android native app ===
* Updates:
** Continuing development of Suggested Edits v3 (update of user statistics
screen)
** Will release maintenance update to Production this week.
=== Structured Data ===
* Updates:
** continuing with MachineVision, input types for structured data, campaigns
=== Parsing ===
* Updates:
** Parsoid-PHP: We are now down to the last handful of bugs before we will
be "green" in roundtrip testing (i.e no unexplainable test differences wrt
Parsoid/JS).
** In conversations with CPT (Services) & SRE about Parsoid/PHP
predeployment and charting a path and timeline for it.
=== Language ===
* Updates:
** Moving MT disable/enable config from cxserver to mediawiki-config with
next week's train: [[phab:T232986]]
=== UI Standardization ===
* Updates:
** Special:Contributions got transformed to OOUI and in the course improved
user-experience and made it mobile ready, related to AMC work.
[[phab:T117736]] Thanks to Jdlrobson and Bartosz on helping
** Collapsible/expandable OOUI core forms are improved in user
interoperability (full width/height interactive area), discoverability and
accessibility (correctly exposed to screen readers)
** No OOUI release this week, waiting for MW 1.35 cut next week
** Continued work on Design Style Guide Components section
== Technology ==
=== Analytics ===
* Blocking:
** Search Platform: [[phab:T229882]]
=== Fundraising Tech ===
* Updates:
** CiviCRM
*** End of year summary emails: [[phab:T195907]]
*** batch fixing of typo-ed email domains: [[phab:T231332]]
** CentralNotice
*** Running new banner view & landing page data pipeline, will compare with
old one
*** Putting finishing touches on campaign fallback feature before merging.it
to master: [[phab:T232859]]
** Payments-wiki
*** Payment method display tweaks for India bank transfer: [[phab:T231452]]
=== Core Platform ===
* Blocked by:
** SRE on Logging for the session storage service [[phab:T209110]]
* Blocking:
** Search Platform: RecentChange support for SDC: [[phab:T230862]]
** Wikidata: Not sure who, Core Platform? We would appreciate some input
on/triaging [[phab:T225814]]
* Updates:
** RFC for REST API namespaces and version [[phab:T232485]]
** Outreachy proposals done
** First version of iOS history API by Sep 30
** Echo notification storage changes coming
** Kask performance issues unblocked
=== Engineering Productivity ===
==== Release Engineering ====
* Updates:
** REMINDER: We're at 1.34.0-wmf.24 this week. The last branch for this
release will be wmf.25 on 30 September. Teams who want to ship things for
MW 1.34 should land them now. [[phab:T232026]] (If you do not mark code as
deprecated in the next few weeks, you have to maintain it for another nine
months.)
** Creating accounts was broken on beta cluster since 2019-09-08. It was
fixed today (2019-09-25). [[phab:T232796]]
** Train Health
*** Last week: 1.34.0-wmf.23 - [[phab:T220748]]
*** This week: 1.34.0-wmf.24 - [[phab:T220749]]
*** Next week: 1.34.0-wmf.25 - [[phab:T220750]]
=== Search Platform ===
* Blocked by:
** Core Platform (or Multimedia?): RecentChange support for SDC:
[[phab:T230862]]
** Analytics: [[phab:T229882]]
* Updates:
** Fixed hascaption includes files that have had their captions removed:
[[phab:T231038]]
=== Site Reliability Engineering ===
* Blocking:
** CPT on Logging for the session storage service [[phab:T209110]]
* Updates:
** Restrouter has been deployed
** S4 primary database master switchover scheduled for Thursday 26th at
05:00 AM UTC (read-only required) [[phab:T230784]]
== Wikimedia DE ==
=== Wikidata ===
* Blocked by:
** Not sure who, Core Platform? We would appreciate some input on/triaging
[[phab:T225814]]
== SoS Meeting Bookkeeping ==
* Updates:
** Please remember not to read all updates, only ones that would be
interesting to people outside of your team
** Please remember to copy/paste tasks from your team's "blocking" section
to "blocked by section" of the appropriate team
** As an experiment, I'm using a tool to create short Gerrit, Git,
MediaWiki, Phabricator and Wikitech links for meeting notes. Let me know
what you think. For an example, see [[Scrum_of_scrums/2019-09-18]]
Dear all,
I thank you for your efforts. I am honoured to inform you that our latest research paper about Wikidata and Health has been published in Journal of Biomedical Informatics (IF=2.9). The paper is available at https://doi.org/10.1016/j.jbi.2019.103292. This paper is the first one of our series of research publications about Medical Wikidata project. If you like to have the paper, please contact me and I will send the PDF to you. Our next papers will work on finding methods to ameliorate the coverage and quality of medical information in Wikidata. We are quite sure that our work is important as it will be provide trustworthy reference medical information that can be used by physicians and computer programs to process medical data and enhance the efficiency of health care.
Yours Sincerely,
Houcemeddine Turki (he/him)
Medical Student, Faculty of Medicine of Sfax, University of Sfax, Tunisia
GLAM, Research and Education Coordinator, Wikimedia TN User Group
Member, Wiki Project Med
Member, WikiIndaba Steering Committee
Member, Wikimedia and Library User Group Steering Committee
____________________
+21629499418
The deployment of 1.34.0-wmf.24 to group0 was delayed until late Tuesday,
night/evening. More specifically, I promoted the branch to group0 just
about 20 minutes ago at approximately 03:30 UTC / 8:30 PM San Francisco.
Group 1 is scheduled for tomorrow between 19:00 - 21:00 UTC.
There are currently several open tasks with status Unbreak Now!, however,
none are marked as train blockers. From a brief review of comments, it
appears that all of them had a fix merged prior to the branch cut and
remain open pending QA review. If any issues remain please let me know,
ideally by adding issues as blockers under T220749[1] sometime before 19:00
UTC. If you need more time to test prior to the rollout of group1 then you
can reach me via IRC or email to coordinate.
[1] Tasks marked Unbreak now!
https://phabricator.wikimedia.org/maniphest/query/AtbLhf4ZUBGj/
[2] Train blockers for 1.34.0-wmf.24
https://phabricator.wikimedia.org/T220749
Happy testing!
Your humble train conductor, Mukunda
Phabricator: @mmodell
IRC: twentyafterfour
Hello everyone,
I would like to share a quick summary of Small Wiki Toolkits, which was one
of the focus areas at this year’s Wikimania Hackathon.
As part of this focus area, five workshops and two sessions were conducted
that covered a wide range of topics – developing user scripts and gadgets,
working with Wikimedia APIs, writing templates in Lua, generating Wikidata
infoboxes, leveraging Wikimedia cloud services, etc. Participants also
engaged in other activities such as the Wikidata documentation translation
sprint and cleaning MediaWiki:Common.css with TemplateStyles.
All toolkits are now available on the Meta page:
https://meta.wikimedia.org/wiki/Small_wiki_toolkits. You can also add this
page to your Watchlist to keep up to date with the next steps on this
project!
To learn more, read the complete summary on Wikimedia Space:
https://space.wmflabs.org/2019/09/24/round-up-of-small-wiki-toolkits-at-wik…
Cheers,
Srishti
*Srishti Sethi*
Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello all,
On my own mediawiki install, I am trying to add another checkbox field to the Special:CreateAccount page. I have found the code responsible for the form, but for some reason the checkbox does not show up. As a test, I then went and tried copying and pasting one of the existing text boxes (with its IDs etc changed of course) to see if that would work. Nothing shows up other than the fields already present.
Does anyone have any ideas what could be blocking it and/or what I am missing? Below is the diff of the change that doesn’t show.
https://github.com/TheSandDoctor/misc-code-bits/commit/4f2f6221c64095777622…
Thanks!
TheSandDoctor
The code review working group has been discussing ideas for how to
encourage more / better code reviews for Wikimedia code.
One idea that we are exploring[1] is something we tried previously which
was called "Code review office hours." This was a weekly scheduled IRC
meeting attended by code reviewers. The previous incarnation was a minor
success but eventually interest petered out and we canceled the scheduled
meetings.
So in bringing back the code review meetings, we want to try something a
bit different. A couple of ideas proposed so far:
* Have more focused meetings around specific parts of the code base or
specific features.
* Rebrand as "Patch triage" and focus more on an initial code
review/feedback on new patches rather than focusing on merging as we did
previously.
I'm writing this to raise awareness and encourage participation, as well as
feedback about the current proposals. We won't be successful without
participation from code reviewers as well as code contributors so your
feedback and participation are important and appreciated. If this interests
you, please join the discussion on the Phabricator taskl[1].
1. T229512 "Review and refine the Code Review Office Hours model of
engagment" https://phabricator.wikimedia.org/T229512
Hello,
Startup module, is the Javascript code [1] that is being served at almost
every request to Wikimedia as part of <head> (non-blocking though) to load
other RL modules. It does important things for example it checks if the
requested modules already exist with the given hash in the local storage
cache.
Because of the given reasons, the startup module needs and includes list of
all registered modules with their version hash in the code. As the result
if you register a module, even if you don't load it, it adds a rather small
overhead (around 19 bytes after minification and compression) to every
request to any wiki the code is enabled. So if you register a new module in
core or one of the extensions that is deployed in all wikis (CX,
WikibaseClient, etc.), it's going to be added to every page request,
meaning 30 GBs more traffic every day to our users. Even if you don't use
it anywhere.
If you're adding a feature, 30GB/day is acceptable but sometimes developers
use Resource loader for dependency management or class loading (yours truly
used to do that) and introduce 20 modules instead of one and each one
causing an extra 600 GB/day. The big overhead for our users is bad for
three reasons: 1- RL has to handle the dependency management, making every
page view slightly slower and worse UX for our users 2- The extra network
is bad with places without access to broadband connection, where Wikipedia
is the most likely place that people learn and grow [2] 3- The scale we are
talking is so massive (petabytes a year) that It has environmental impact.
Let me give you an example, a couple of weeks ago we dropped 137 modules
from WikibaseClient. After deployment, it dropped 4TB/day from our network
(= 1.5 PB/year) and synthetic data shows, in an average case we drop 40 ms
from every response time [3].
We now have a dashboard to track size of size of RL registry [4] plus a
weekly metrics for changes [5][6]
If you're looking for ways to help. I wrote a tool [7] to do some graph
analysis and it gives list of extensions that has modules that can be
merged. The extensions that according to the analysis (that can have false
positives) can get better are TimedMediaHandler, PageTriage, Graph,
RevisionSlider, CodeMirror, Citoid, TemplateData, TwoColConflict,
Collection, CentralNotice, AdvancedSearch, 3D, MobileFrontend and many more
including some bits and pieces in core. I put the graphs of modules that
can be merged at [8] and I invite you to have fun with those modules.
Modules can be merged using package modules [9]
Most of the is work done by the performance team [10] and volunteers and
developers in lots of teams. I joined the party later as volunteer/WMDE
staff and I'm sharing mostly the results and writing long emails. Big kudos
to Krinkle, James Forrester, Santhosh Thottingal, Jon Robson, Alaa Sarhaan,
Alexandros Kosiaris, and so many others that helped and I forgot.
[1] An example from English Wikipedia:
https://en.wikipedia.org/w/load.php?lang=en&modules=startup&only=scripts&ra…
[2] https://arxiv.org/abs/1812.00474
[3] https://phabricator.wikimedia.org/T203696#5387672
[4] https://grafana.wikimedia.org/d/BvWJlaDWk/startup-module-size?orgId=1
[5] https://gist.github.com/Krinkle/f76229f512fead79fb4868824b5bee07
[6]
https://docs.google.com/document/d/1SESOADAH9phJTeLo4lqipAjYUMaLpGsQTAUqdgy…
[7] https://phabricator.wikimedia.org/T232728
[8] https://phabricator.wikimedia.org/T233048
[9] https://www.mediawiki.org/wiki/ResourceLoader/Package_modules
[10] https://phabricator.wikimedia.org/T202154
Best
--
Amir (he/him)
Well, I'm thrilled about this, especially after having had a look
through https://www.slideshare.net/lucidworks/searching-for-better-code-presented-b…
Honestly, though, it's only the third best thing that happened this
week after Valerie Plame entering politics and the UC system divesting
from fossil fuels.
Grant, welcome! My advice is to set make a long list of concrete KPIs
for contributor (e.g. editor) support, reach, and cloud support, in a
way that can be used for fundraising. The fundraising messaging has
been stuck for years on this thing about, "if everyone reading this
contributed the cost of a cup of coffee, then _some goal here_," which
is okay, but could be so much better flipped with the KPIs as the ask,
e.g., "Each $CURRENCY you donate will pay to support N additional
$CONTENTS," where the wikipedias can use ops measurements of the
resources typical to, e.g., take an article from Start to B class, for
example, or how much time, server electricity including idle time, and
other resource it takes to get a new word added to Wiktionary to some
level of proficiency. If these units relate to the potential donor's
language or geography, all the better. People geolocated in the
developed world using languages with highly developed wikipedias and
wiktionaries can be told how much it would cost to, for example,
eliminate units of the various WP:BACKLOG items you find suitable in
multivariate e.g. Latin squares donation message testing. (Or add new
technology projects like an intelligibility- and natural spoken
feedback version of https://www.speechace.co/api_sample/ hint
https://phabricator.wikimedia.org/T166929#5473028 hint.)
Also please take Curecoin instead of Bitcoin, even if that means
paying the extra transaction fee before converting the Curecoin to
cash. It is the height of folly to be as close to endorsing wasted
electricity-based cryptocurrency as we already do, when alternatives
with a benefit are less commonly known. The only other blockchain
thing I like is that long-term state-sponsored censorship mitigation
program can be based on copying the dumps to IPFS, but please also
support the CDN efforts like Encrypted-SNI:
https://twitter.com/jsalsman/status/1142172682751864832https://twitter.com/jsalsman/status/1142940652851695616https://twitter.com/jsalsman/status/1053786384463355905
Please let me know your thoughts.
Best regards,
Jim