This is the weekly TechCom board review in preparation of our meeting on
Wednesday. If there are additional topics for TechCom to review, please let us
know by replying to this email. However, please keep discussion about individual
RFCs to the Phabricator tickets.
Activity since Monday YYYY-MM-DD on the following boards:
https://phabricator.wikimedia.org/tag/techcom/https://phabricator.wikimedia.org/tag/techcom-rfc/
Committee inbox:
* Remove legacy ajax interface T42787
<https://phabricator.wikimedia.org/T42787>
o Very old task. We should just do it.
Committee board activity:
* Create WikiTeq group on Gerrit T267213
<https://phabricator.wikimedia.org/T267213>
o We should just add WikiTeq to the policy page
New RFCs: none
Phase progression:
* PHP microservice for containerized shell execution (aka ShellBox) T260330
<https://phabricator.wikimedia.org/T260330>
o Last call should have ended last week. Some discussion during last call
period. New comment asking why this should be written in PHP.
o Code is already merged, though not used yet.
o Can probably be approved.
* Amendment to the Stable interface policy T268326
<https://phabricator.wikimedia.org/T268326>
o Question about new requirement to wait at least thee month between hard
deprecation and removal.
o Moved to phase 4
* PageIdentity T208776 <https://phabricator.wikimedia.org/T208776>
o Thiemo (WMDE) asking about some details
o Daniel would like this to go on last call.
Other RFC activity:
* Expand API title generator to support other generated data T263841
<https://phabricator.wikimedia.org/T263841>
o Tim says this is fine and should go ahead
o Do we need a last call?
* Provide mechanism for defining and utilizing configuration sets for local
development and browser / API-testing tests T267928
<https://phabricator.wikimedia.org/T267928>
o Continued discussion after IRC meeting
o Adam Wight emphasizes the need to have config controlled per-request,
rather than changing config on disk.
* Store WikibaseQualityConstraint check data in persistent storage T214362
<https://phabricator.wikimedia.org/T214362>
o WMDE would like this to move forward. Resourcing is not really clear.
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
Hi all,
Tomorrow we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.31.11
- 1.35.1
This will resolve 5 issues in MediaWiki core (1 of which isn't applicable
to MediaWiki 1.31 at all), and also includes some fixes previously
committed to git, including minor security and hardening patches along with
bug fixes included for maintenance reasons.
We will make the fixes available in these respective release branches, and
also master. 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.
As per the MediaWiki Version lifecycle [1], November 2020 was the scheduled
EOL date for the REL1_34. MediaWiki 1.35.1 will be supported until at least
September 2023, and would be the recommended upgrade path for anyone still
using 1.34.
[1] https://www.mediawiki.org/wiki/Version_lifecycle
https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-12-16
= 2020-12-16 =
== Callouts ==
* Last train of the year happening this week!
* All welcome to propose cross-Wikimedia standards for Vue code, on
https://www.mediawiki.org/wiki/Manual:Coding_conventions/Vue (and talk page)
** API Platform is live! https://api.wikimedia.org/
== No updates ==
TechCom, Web, Prod Infra, Inuka, OKAPI, Analytics, Cloud Services, Quality
and Test, Machine Learning Platform, Research, Search Platform, Wikidata,
and German Technical Wishlist
== SoS Meeting Bookkeeping ==
* Updates: asynch retro form coming
== Product ==
=== Community Tech ===
* Blocked by:
* Blocking:
* Updates: No Updates
=== Anti-Harassment Tools ===
* Blocked by:
* Blocking:
* Updates:
** Deploying IPInfo extension to Beta Cluster this week - thank you to
everyone who has helped
=== Editing ===
* Blocked by:
* Blocking:
* Updates:
** No updates, team offsite
=== Growth ===
* Blocked by:
* Blocking:
* Updates:
** continuing work on link recommendations:
https://wikitech.wikimedia.org/wiki/Add_Link
** added pageid: CirrusSearch keyword:
https://www.mediawiki.org/wiki/Help:CirrusSearch#Pageid (thanks to Search
Platform for their help!)
** added a community notice module to Special:Homepage after realizing we
were interfering with a big arwiki content campaign
https://phabricator.wikimedia.org/T269804
** changed message handling in skin tabs for better gender support:
https://phabricator.wikimedia.org/T47938
** preparing to deploy GrowthExperiments on bnwiki
https://phabricator.wikimedia.org/T266020
=== iOS native app ===
* Blocked by:
* Blocking:
* Updates: Going to stand up a labs instance for some simple caching the
next experiment coming down the pipeline. Don't think this is blocked by
anything, but if the team gets stuck, we may need help.
=== Android native app ===
* Blocked by:
* Blocking:
* Updates: Working w/ community tech team on ensuring we have APIs
available for the Android Watchlist work that has been designed. After some
research, believe we have everything needed.
=== Structured Data ===
* Blocked by:
* Blocking:
* Updates:
** MediaSearch: continuing to improve and tune back-end, front-end bug fixes
** Media matching: continuing architectural discussions across teams
** Instrumenting event logging for VE's image search (
https://phabricator.wikimedia.org/T265101 )
** Hoping to get some blog posts written about our experience working with
Vue
=== Abstract Wikipedia ===
* Blocked by:
* Blocking:
* Updates:
** Continuing work on using ZType data to enforce structure when editing
ZObjects.
** Starting review of our Vue.js practices now the team has two members.
All welcome to propose cross-Wikimedia standards on
https://www.mediawiki.org/wiki/Manual:Coding_conventions/Vue
=== Parsing ===
* Blocked by:
* Blocking:
* Updates: no updates
=== Language ===
* Blocked by:
* Blocking:
* Updates:
** Apertium service migration is done (Remaining thing will be done by SRE
mostly in January).
=== Library ===
* Blocked by:
* Blocking:
* Updates:
** Migrated The Wikipedia Library images from DockerHub to Quay.io
** Wikilink performance improvements have been merged
=== UI Standardization ===
* Blocked by:
* Blocking:
* Updates:
** No new OOUI release this week.
== Technology ==
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** More work on CentralNotice campaign preferences:
https://phabricator.wikimedia.org/T268646
** Working on donor email preference center:
https://phabricator.wikimedia.org/T268495
** Getting more of our dev-environment dockerized:
https://phabricator.wikimedia.org/T262975
** Prepping another CiviCRM upgrade, testing new search features on
staging: https://phabricator.wikimedia.org/T270216
=== Platform ===
* Blocked by:
* Blocking:
* Updates:
** API Platform is live! https://api.wikimedia.org/
** ParserCache work for REST API
** MW on K8S and Shellbox
** Sockpuppet Detection API closing in on completion
** Task recommendation API ramping up
=== Engineering Productivity ===
==== Performance ====
* Blocked by:
* Blocking:
* Updates:
** Nothing to update.
==== Release Engineering ====
* Blocked by:
**
* Blocking:
** ???
* Updates:
** [All] Deployments/Covid-19
https://wikitech.wikimedia.org/wiki/Deployments/Covid-19
** Train Health
*** Last week: 1.36.0-wmf.21 [[phab:T263187]] <!--
https://phabricator.wikimedia.org/T263187 -->
*** This week: 1.36.0-wmf.22 [[phab:T263188]] <!--
https://phabricator.wikimedia.org/T263188 -->
** Next week: No Train and no deploys!
** Rest of the year: No Train and no deploys!
=== Security ===
* Blocked by:
** none
* Blocking:
* Updates:
** Q3 review queue is almost set / full - pls message soon if you have
plans that will require a security review.
** In Progress: ISBN Barcode Scanner -
https://phabricator.wikimedia.org/T269007
** In Progress: Section Translation -
https://phabricator.wikimedia.org/T260236
** In Progress: IP Info extension -
https://phabricator.wikimedia.org/T260822
=== Site Reliability Engineering ===
* Blocked by:
** None
* Blocking:
** Growth on adding LVS configs for linkrecommendation
** Search for adding k8s configs for flink
* Updates:
** Kunal joins ServiceOps SRE.
** Giuseppe and Effie have given a talk at SRECon
** mw1265 being reimaged to buster
== Cross-cutting ==
* Blocked by:
* Blocking:
* Updates:
** Work proceeds on making MW, extensions and libraries PHP 8.0-compatible
(target is back-porting to REL1_35, for our sins); expect another round of
mediawiki-tools-phan updates https://phabricator.wikimedia.org/T248925
[[Category:Scrum of scrums{{#translation:}}|*]]
Hello,
The focus area "Better support for geographic information"[1] was the
winner in the survey "Technical wishes 2020" in German Wikipedia. This
means the Team Technical wishes[2] will spend two years on this topic
and tackle various problems in it. As a first step for this, the
research for problems and needs is currently running. Therefore,
everyone is invited to collect, structure, develop and discuss
problems, wishes and project ideas here:
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Geoinformation/Ideas
Cheers,
Michael for the Technical Wishes Project of Wikimedia Deutschland
[1]: https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Geoinformation
[2]: https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes
--
M. F. Schönitzer
Community Communication
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 Wissen der
Menschheit teilhaben, es nutzen und mehren können. Helfen Sie uns
dabei!
https://spenden.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.
We invite all registered users to vote on the 2021 Community Wishlist
Survey[1]. You can vote until 21 December for as many different wishes as
you want.
In the Survey, wishes for new and improved tools for experienced editors
are collected. After the voting, we will do our best to grant your wishes.
We will start with the most popular ones.
We, the Community Tech[2], are one of the Wikimedia Foundation[3] teams. We
create and improve editing and wiki moderation tools. What we work on is
decided based on results of the Community Wishlist Survey. Once a year, you
can submit wishes. After two weeks, you can vote on the ones that you're
most interested in. Next, we choose wishes from the survey to work on. Some
of the wishes may be granted by volunteer developers or other teams.
We are waiting for your votes. Thank you!
[1]
https://meta.wikimedia.org/wiki/Special:MyLanguage/Community_Wishlist_Surve…
[2] https://meta.wikimedia.org/wiki/Special:MyLanguage/Community_Tech
[3] https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation
Kind regards,
Szymon Grabarczuk (he/him)
Community Relations Specialist
Wikimedia Foundation <https://wikimediafoundation.org/>
Datavalues with complex structure (time, quantity, globecoordinate) have properties (e.g. latitude, longitude, precision, amount, unit, etc.) that link from a node that is the value of a statement, reference, or qualifier. In my question, I'm going to refer to those nodes as "value nodes".
When performing a SPARQL query at the WD Query Service (example: https://w.wiki/ptp), these value nodes are identified by an IRI such as wdv: 742521f02b14bf1a6cbf7d4bc599eb77 (http://www.wikidata.org/value/742521f02b14bf1a6cbf7d4bc599eb77). The local name part of this IRI seems to be a hash of something. However, when I compare the hash values from the snak JSON returned from the API for the same value node (see https://gist.github.com/baskaufs/8c86bc5ceaae19e31fde88a2880cf0e9 for the example), the hash associated with the value node (35976d7cb070b06a2dec1482aaca2982df3fedd4 in this case) does not have any relationship to the local name part if the IRI for that value node.
This situation differs from that of identifiers for references, whose IRIs (wdref:8eb6208639efa82b5e7e4c709b7d18cbfca67411 = http://www.wikidata.org/reference/8eb6208639efa82b5e7e4c709b7d18cbfca67411 in this example) are clearly formed from the hash associated with the reference hash in the snak JSON returned from the API (8eb6208639efa82b5e7e4c709b7d18cbfca67411).
I am using the JSON returned by the API after writing new data to track those data at a later time via the Query Service. So I would like to know if there is a way that the value node IRIs can be determined from information in the JSON returned from the API. This is easy to do for reference and statement IRIs, but is not obvious for value nodes.
Thanks!
Steve Baskauf
--
Steven J. Baskauf, Ph.D.
Data Science and Data Curation Specialist
Jean & Alexander Heard Libraries, Vanderbilt University
Nashville, TN 37235, USA
Office: Eskind Biomedical Library, EMB 111
Phone: (615) 343-4582
https://my.vanderbilt.edu/baskauf/
https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-12-09
= 2020-12-09 =
== Callouts ==
* If you know anyone who might have something web performance related to
talk about (including outside of the Foundation), please point them to our
FOSDEM devroom CfP. Deadline is Dec 16:
https://github.com/wikimedia/fosdem21-web-performance-cfp Thanks!
* RelEng: 1.36.0-wmf.22 is the last train of the year. Next week is the
last deployment week of the year.
*No updates:* Tech Comm, Anti-Harassment Tools, Editing, Product
Infrastructure, Parsing, Inuka, UI Standardization, OKAPI, Analytics, Cloud
Services, Quality and Test Engineering, Machine Learning Platform,
Research, Search Platform, Security, SRE, Wikidata, German Technical
Wishlist
== SoS Meeting Bookkeeping ==
* Updates:
* asynchronous retrospective on value of this experiment.
* adding new section to notes template for cross-cutting work
== Product ==
=== Community Tech ===
* Blocked by:
* Blocking:
* Updates:
** We've now moved to the voting phase of the Community Wishlist Survey.
We've accepted 270 proposal and at the time of writting there are 2571
supporting votes (
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Tracking )
=== Growth ===
* Blocked by:
* Blocking:
* Updates:
** Working on various bits and pieces (frontend, backend, ops) of
https://wikitech.wikimedia.org/wiki/Add_Link
=== iOS native app ===
* Blocked by:
* Blocking:
* Updates:
** Recent release even more stable than last.
** Working on language variants and other bug fixes.
=== Android native app ===
* Blocked by:
* Blocking:
* Updates:
** Working on watchlist feature, which was well-scoped to be a well-sized
feature while between Product Managers.
=== Web ===
* Blocked by:
* Blocking:
* Updates:
** WVUI-Vector integration
*** Preparing for Security Readiness Review:
https://phabricator.wikimedia.org/T257579
*** Product metrics and performance instrumentation
*** Client-side error logging: https://phabricator.wikimedia.org/T249826
** Designs for language switching re-design(s) in Desktop Improvements
Program
*** https://phabricator.wikimedia.org/T268514
***
=== Structured Data ===
* Blocked by:
* Blocking:
* Updates:
** Working on Commons Special:MediaSearch
** Released a tool to assess quality of media search image results:
https://media-search-signal-test.toolforge.org/ (warning: you may see NSFW
images)
=== Abstract Wikipedia ===
* Updates:
** Continuing work on using ZType data to enforce structure when editing
ZObjects.
** Helping our Outreachy interns get started doing data anaylsis of
template/module usage.
** Great modelling conversations with SRE Service Ops and Architecture;
thank you.
=== Language ===
* Blocked by:
* Blocking:
* Updates:
** Apertium is now migrated to `deployment-pipeline` and available as a
service. Thanks Alexandros Kosiaris (SRE) for helping in the process!
=== Library ===
* Blocked by:
* Blocking:
* Updates:
** Wrapping up work on Wikilinks (we hope to get a PR merged this week)
== Technology ==
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** Readying a CentralNotice feature for logged-in users to filter out of
banner types in user preferences, hoping to deploy very soon after current
fundraiser ends. Will be asking core team for feedback on user preference
UI change. https://phabricator.wikimedia.org/T268646,
https://gerrit.wikimedia.org/r/604279,
** fixing some session timeout bugs in the synchronization of data from our
bulk mail sender to CiviCRM
** form tweaks to help when we switch over from raising money for the
annual fund to raising money for the endowment
** More work on dockerized dev environment:
https://phabricator.wikimedia.org/T262975
=== Platform ===
* Blocked by:
* Blocking:
* Updates:
** API Portal bug unblocking (next week soft launch)
** ParserCache work (some bugs occuring from use of ParserOutput)
** Shellbox (MediaWiki on Kubernetes)
** Sockpuppet Detection API
** Task recommendations API
=== Engineering Productivity ===
==== Performance ====
* Blocked by:
* Blocking:
* Updates:
** Blog post:
https://calendar.perfplanet.com/2020/human-performance-metrics/
** Another one from Timo about Excimer will be published there in a few
days.
==== Release Engineering ====
* Blocked by:
**
* Blocking:
**
* Updates:
** Thanks to Andrew and Arturo for their help with nest VM support on WMCS
instances
** Deployments
*** Last week: 1.36.0-wmf.20 [[phab:T263186]] <!--
https://phabricator.wikimedia.org/T263186 -->
*** This week: 1.36.0-wmf.21 [[phab:T263187]] <!--
https://phabricator.wikimedia.org/T263187 -->
*** Next week: 1.36.0-wmf.22 [[phab:T263188]] <!--
https://phabricator.wikimedia.org/T263188 -->
*** Rest of the year: https://wikitech.wikimedia.org/wiki/Deployments
(nothing!)
Hi All,
Every year we stop deployments for the last full week of the year.
As we enter the last couple weeks of the year, I wanted to send out a
reminder that next week is the final deployment week of the year and that
wmf/1.36.0-wmf.22 will be the last train release of the year.
The deployment calendar on Wikitech
<https://wikitech.wikimedia.org/wiki/Deployments> is up-to-date and is the
canonical source for the deployment schedule.
Thank you!
-- Tyler