FYI
---------- Forwarded message ----------
From: Daniel Zahn <dzahn(a)wikimedia.org>
Date: 27 March 2018 at 19:24
Subject: [Ops] new deployment server (tin -> deploy)
To: Operations Engineers <ops(a)lists.wikimedia.org>
Hi,
good old tin.eqiad.wmnet was out of warranty and running jessie,
so as part of our hardware refresh goal it had to be replaced by something
new.
We now have deploy1001.eqiad.wmnet and it's running on stretch with PHP7
and we just switched deployment servers and Mukunda is running the first
deploy from it as we speak.
<+logmsgbot> !log twentyafterfour@deploy1001 Started scap: Deploy
1.31.0-wmf.27 to test wikis
Here are the related puppet changes that switched it and added stretch
support:
https://gerrit.wikimedia.org/r/#/q/project:operations/
puppet+branch:production+topic:deploy1001
Additionally mwscript needed a way to detect php5 or php7, for that see:
https://gerrit.wikimedia.org/r/#/c/422348/
There are also more details on today's SAL and on:
https://phabricator.wikimedia.org/T175288
tin has not been killed yet and for now remains a scap master, just in case.
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
_______________________________________________
Ops mailing list
Ops(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ops
Greetings!
We are beginning the process of working on the 1.31 release of MediaWiki.
The release is currently scheduled for June. We plan to create the REL1_31
branch on April 17 and to generate the first release candidate, so we will
be requesting "pencils down" on April 16.
In the meantime, if you have any open Phabricator tasks tagged with
mw-1.31-release [0], please check to see if they are indeed blockers for
the release. If not, please remove the mw-1.31-release tag from them.
Conversely, if there are any blockers that are not tagged with
mw-1.31.release, please tag them. Please feel free to reach out to me if
you have any questions about this.
We will be in the normal patch master + backport process from April 17
until the release in June.
Thanks,
Cindy
[0] https://phabricator.wikimedia.org/tag/mw-1.31-release/
______________________________
Cindy Cicalese
Product Manager, MediaWiki Platform
Wikimedia Foundation
FYI: tomorrow much of our CI tests will not run due to a planned
Wikimedia Cloud reboot.
Sorry for the inconvenience.
Greg
----- Forwarded message from Andrew Bogott <abogott(a)wikimedia.org> -----
> Date: Tue, 27 Mar 2018 09:34:55 -0500
> From: Andrew Bogott <abogott(a)wikimedia.org>
> To: Cloud-announce(a)lists.wikimedia.org
> Subject: [Cloud] [Cloud-announce] Brief service interruption tomorrow 2018-03-28 at 15:00 UTC
> Reply-To: cloud(a)lists.wikimedia.org
>
> About 24 hours from now we're going to reboot a couple of servers[1] in the
> cloud infrastructure to apply security updates.
>
> Few WMCS users (and, in particular, no tools users) should notice any
> interruption. Nonetheless, a few services will be down:
>
>
> - New instance creation will fail
>
> - CI tests will stop running
>
> - Horizon and Wikitech may display incorrect or missing information
>
>
> Apologies in advance for any inconvenience!
>
>
> -Andrew
>
>
> [1] labservices1001 and labcontrol1001
>
>
> _______________________________________________
> Wikimedia Cloud Services announce mailing list
> Cloud-announce(a)lists.wikimedia.org (formerly labs-announce(a)lists.wikimedia.org)
> https://lists.wikimedia.org/mailman/listinfo/cloud-announce
> _______________________________________________
> Wikimedia Cloud Services mailing list
> Cloud(a)lists.wikimedia.org (formerly labs-l(a)lists.wikimedia.org)
> https://lists.wikimedia.org/mailman/listinfo/cloud
----- End forwarded message -----
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |
Sorry for cross-posting!
Reminder: Technical Advice IRC meeting again **tomorrow, Wednesday 3-4 pm
UTC** on #wikimedia-tech.
The Technical Advice IRC meeting is open for all volunteer developers,
topics and questions. 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 WMDE’s tech team)
--
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://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/681/51985.
Forwarding to Wikitech-l for the benefit of Wikitech-l subscribers who do
not subscribe to Wikimedia-l.
Pine
( https://meta.wikimedia.org/wiki/User:Pine )
---------- Forwarded message ----------
From: Gregory Varnum <gvarnum(a)wikimedia.org>
Date: Fri, Mar 16, 2018 at 6:57 PM
Subject: [Wikimedia-l] Notification about problem identified with a recent
CentralNotice banner
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
On 14 March and 15 March 2018, a CentralNotice banner appeared to some
logged-out users viewing English Wikipedia pages. The banner contained
JavaScript hosted by Facebook, which allowed Facebook to collect traffic
data from those who visited a page with a banner. The banner was prepared
by the Wikimedia Foundation. The Foundation turned the banner off as soon
as we learned how the script was running, and its potential scope. We have
also removed all references to the code in question from CentralNotice on
Meta-Wiki.
The code utilized in this banner was based on an unused prototype created
by an outside vendor. Because the prototype was never enabled, the vendor’s
prototype code was not subjected to our standard quality assurance process.
However, we made the mistake of reusing the code for a different purpose,
and implementing it based on recommendations in documentation from Twitter
and Facebook to improve the appearance of shared links. At the time, our
understanding was that the platforms would only receive traffic data if the
user clicked on the link. Although this was true for Twitter, the Facebook
code operated differently.
We discovered the problematic link configurations during our ongoing
monitoring of live banners. The recommended code enhanced not only the
appearance of links, it also enhanced Facebook's ability to collect
information on people visiting non-Facebook sites. As soon as we realized
these banners were sharing information without even having to click the
link, we disabled them and began an investigation. Staff in multiple
departments are collaboratively reviewing the incident as well as
procedural and technical improvements to prevent future incidents.
While this sort of tracking is commonplace today across most of the
internet, it is not consistent with our policies. We are disappointed that
this type of hidden data collection is routinely recommended by major
platforms, without clearer disclosure.
These practices are why we all must regularly take routine steps to
maintain a secure computer and account. As the Wikimedia Foundation
continues to explore ways we can do that within Wikimedia's platform, we
encourage you to consider tools which block unwanted third-party scripts
like the one provided by Facebook.
We apologize for sending this late on a Friday (San Francisco time).
However, we wanted to provide this information as quickly as possible.
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
wiki/Wikimedia-l
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Hello everyone,
On behalf of the Parsing Team @ the WMF, I am announcing our plans to
replace Tidy with Remex on the next set of wikis.
On April 4th, we plan to turn off Tidy on all wikiquotes (except
frwikiquote) [1] and wikimedia wikis [2]. 23 wikis will have Tidy replaced.
On April 11th, we plan to turn off Tidy on all wikis with < 50 entries
in all high priority linter categories [3]. About 60 wikis will have
Tidy replaced.
Please follow T175706 [4] to monitor progress of Tidy replacement.
Currently about 600 wikis have had Tidy replaced and we have another 300
wikis to go. We plan to finish this transition from Tidy to RemexHtml by
end of June 2018.
If you have any questions or concerns, please leave a comment on the
associated phabricator tickets or leave a message on mw.org [5].
Thanks,
Subbu.
[1] https://phabricator.wikimedia.org/T188881
[2] https://phabricator.wikimedia.org/T190726
[3] https://phabricator.wikimedia.org/T190731
[4] https://phabricator.wikimedia.org/T175706
[5] https://www.mediawiki.org/wiki/Help_talk:Extension:Linter
TL;DR see <https://phabricator.wikimedia.org/T179461> for a proposed
naming change.
I proposed in Phabricator a wile ago [0] that we adopt the term
"Wikimedia developer account" across our wikis and other documentation
for the LDAP-backed user accounts that are created using
wikitech.wikimedia.org.
These same sign-on credentials are used for:
* wikitech.wikimedia.org
* Gerrit
* Phabricator (optionally)
* toolsadmin.wikimedia.org
* horizon.wikimedia.org
* ssh-based "shell access" to Toolforge and Cloud VPS servers
* a variety of web services providing access to operational and
analytics data related to the Wikimedia services
There are plans [1][2] in various stages of progress to change things
about how developer accounts are created and managed. Breaking
assumptions in our documentation about the back-end storage system
(LDAP) and the front-end management interface (wikitech) will help
make these changes less disruptive. It also helps remove another
lingering "labs" reference that the Cloud Services rebranding efforts
have been trying to address.
This change probably has almost no impact on existing technical
community members. It is really just targeted at making things a bit
less confusing for newcomers.
If you have thoughts or concerns about this proposal, please describe
them on the Phabricator task [0]. I'm proposing that on or about March
23rd (4 weeks from the date of this message) the comments on the task
will be evaluated for consensus and an approve/deny decision.
[0]: https://phabricator.wikimedia.org/T179461
[1]: https://phabricator.wikimedia.org/T161859
[2]: https://phabricator.wikimedia.org/T179463
Thanks,
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Manager, Cloud Services Boise, ID USA
irc: bd808 v:415.839.6885 x6855
Hello everyone,
We are releasing the next version of the Parsoid deb and npm packages
(v0.9.0) later today. There is one significant change in this release
that might affect some VisualEditor installations. This version of
Parsoid wraps sections in <section> tags and bumps the HTML version to
1.6.1. However, VisualEditor installations older than Dec 12, 2017 are
not compatible with this section wrapped output.
In order to prevent silent failures, Parsoid will do a hard fail and
reject parse requests with a HTTP 406 when it receives a version string
smaller than 1.6.0 (which VE before Dec 12, 2017 would issue). VE will
then popup the following error: "Error loading data from server:
apierror-visualeditor-docserver-http: HTTP 406. Would you like to
retry?" Retries won't help in this scenario.
Knowing this, you have a couple of options:
* Not upgrade Parsoid. If you upgrade Parsoid without reading this
notice and later stumble on this (which we'll also add to the
Parsoid releases page), you have the option of downgrading your
Parsoid install by downloading an older deb package from
https://people.wikimedia.org/~ssastry/parsoid/debs/
* If you choose to upgrade Parsoid and your VE installation is from
before Dec 12, 2017 (which is probably most of you), the recommended
solution is to upgrade your VisualEditor installation as well.
If for some reason you really really need to upgrade Parsoid but cannot
upgrade VisualEditor, contact us on IRC in #mediawiki-parsoid to ask us
how you can do that.
Subbu.
(on behalf of Parsoid developers).
Hello everyone,
I'm excited to announce that we've released OOUI v0.26.0 today. It
will be in MediaWiki core from 1.31.0-wmf.26, which will be deployed
to Wikimedia production in the regular train, starting on Tuesday 27
March.
In this breaking release email I would like to begin with pointing out
two “normal” changes with visible user-interface amendments:
- The Design team at the Wikimedia Foundation has established new icon
guidelines over the course of recent months – resulting in a new set
which is part of this release. The set features improved universality,
consistency, neutrality, developer-friendliness and RTL language
support.
- We took the chance of integrating those icons by also unifying
VisualEditor interface on same base size as all other Vector/OOUI
interfaces already had in place. While this leads to a minimal
increase of space (f.e. 2px in height) for the toolbar items, it
reduces and optimizes the interface in all existing OOUI-based
Special:Pages and extensions.
As there are seven breaking changes in this release, at least
nominally, please carefully consider if they affect your code:
* icons: Remove 'alignCentre', renamed in v0.24.2
* icons: Remove 'arrowLast', deprecated since v0.25.0
* icons: Remove 'bellOn', deprecated in v0.25.0
* icons: Remove 'quotesAdd', deprecated in v0.24.4
* icons: Remove 'redirect', renamed in v0.24.4
* indicators: Remove 'next' and 'previous', deprecated in v0.25.0
All six changes above have been deprecated and announced in former
versions. With this release we've removed them completely.
* WikimediaUI theme: Unify available variants across icon packs
This could affect 'wikimedia' pack users with icons set to
'progressive'. Due to branding guideline reasons we need to remove
this color variation We are not aware of any such use case in
production, nonetheless mark it breaking.
Please update your icon pack references accordingly in case you're
using one of those icons or variants.
Additional details on 12 new features, 53 code-level and accessibility
changes, 18 styling and interaction design amendments, and all
improvements since v0.25.0 are in the full changelog[0]. If you have
any further queries or need help dealing with breaking changes, please
let me know.
As always, library documentation is available on mediawiki.org[1], and
there is comprehensive generated code-level documentation and
interactive demos hosted on doc.wikimedia.org[2].
[0] - https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md
[1] - https://www.mediawiki.org/wiki/OOUI
[2] - https://doc.wikimedia.org/oojs-ui/master/
Best,
Volker
--
Senior UX Engineer
Wikimedia Foundation
volker.e(a)wikimedia.org | @Volker_E
https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-03-21#Multimedia
= 2018-03-21 =
== Callouts ==
* Fundraising campaigns
https://meta.wikimedia.org/wiki/CentralNotice/Calendar - next up:
Netherlands 2018-04-03 through 2018-05-01
* WMDE needs a Wikidiff2 review: https://gerrit.wikimedia.org/r/404293
== Audiences ==
=== Readers ===
==== iOS native app ====
* Blocked by:
* Blocking:
* Updates:
==== Android native app ====
* Blocked by:
* Blocking:
* Updates:
** Increased rollout of Reading List sync to 50% of Beta audience.
** Blocked on a few minor client-side issues, but should continue full
rollout by end of week.
==== Readers Web ====
* Blocked by:
* Blocking:
* Updates:
*Interrupt work for Hindi Wikipedia campaign (
https://phabricator.wikimedia.org/T190101)
*Discussion around DNT (https://phabricator.wikimedia.org/T187277)
*Improvements and some refactoring to Popups extension
*Quarterly goal dependency update:
** Increase learning by lowering the cost of exploration (Page previews)
*** Turning on virtual page view logging for all wikis (
https://phabricator.wikimedia.org/T189906)
*** Pushing for full-deploy in next 3 weeks. (
https://phabricator.wikimedia.org/T154635)
*** This goal was impacted by interrupt work.
** Continue improving the ways that users can download articles of interest
for later consumption
*** Proton work was delayed until next quarter due to external dependencies
in standing up a production endpoint
==== Readers Infrastructure ====
* Blocked by:
* Blocking:
* Updates:
** New /page/media endpoint is exposed via RESTBase, so apps can test it
and provide feedback.
** /page/metadata and /page/references to follow this week.
===== Maps =====
* Blocked by:
* Blocking:
* Updates:
==== Multimedia ====
* Blocked by: N/A
* Blocking: N/A
* Updates
** Search: Patch for MediaInfo caption indexing nearly complete, WMDE and
Cormac working diligently to get things merged, Search supporting (thanks,
both)
** File page prototyping: Progressing, slowly. Mark to meet with Thiemo
from WMDE to clear some things up.
Quarterly goal dependency update
** Prepare backend infrastructure for structured data search
*** SDC: Search PF/Multimedia/Wikidata
** Wikimedia Technology/Goals/2017-18 Q3#Segment 2: Search integration and
exposure
*** SDC: Research/Multimedia
** Prepare backend infrastructure for structured data search
*** SDC: Search PF/Multimedia/Wikidata
=== Contributors ===
==== Community Tech ====
* Blocked by:
* Blocking:
* Updates:
* GlobalPreferences going live today
* Work on TemplateWizard progressing well
==== Anti-Harassment Tools ====
* Blocked by: None
* Blocking: None
* Updates:
* Work continues on Blocking tools
* Bug fixes to Interaction Timeline
* Research on Harassment Reporting Tool
==== Editing ====
* Blocked by:
* Blocking:
* Updates:
==== Parsing ====
* Blocked by:
* Blocking:
* Updates:
** Tidy has been replaced on all wikiversities today. About 300 more to go
before the end June deadline.
** Whitespace trimming in headings, list items, table cells, headings and
captions (wikitext versions only) has been pushed to production. Found a
bug for which there is a fix in gerrit
** Arlo has been working on the heredocs syntax RFC (
https://phabricator.wikimedia.org/T114432 ) and has a WIP patch @
https://gerrit.wikimedia.org/r/#/c/418198/ if someone wants to test and
play with it on your local dev wikis.
*Quarterly goal dependency update:
** Support work towards unifying MediaWiki's parser implementations, in
liaison with Technology's MediaWiki team
*** Parsing:Mediawiki PF/Services
*** No new updates or blockers.
==== Collaboration ====
* Blocked by:
* Blocking:
* Updates:
** Flow uninstalled from wikis where it was unused; can still be requested
by communities, will be re-enabled with local consensus
** Almost done setting up maps test servers in labs
==== Language ====
* Blocked by: None
* Blocking:None
* Updates:
** CX2 work continue;
** Migration to recommend service from Production is planned; WIP.
=== Audiences Design ===
* Blocked by:
* Blocking:
* Updates:
==== UI Standardization ====
* Blocked by:
* Blocking:
* Updates:
** OOUI – v0.26.0 breaking change release
https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md;v…
*** 7 breaking changes, mostly already deprecated icons got removed
*** WikimediaUI theme's new icon set in place
https://phabricator.wikimedia.org/T177432 !
*** Unified VE in Vector/WikimediaUI interface base font-size to usage of
OOUI in core/extensions elsewhere https://phabricator.wikimedia.org/T97631
!
** Style Guide
*** Continued work on v1 goals
https://phabricator.wikimedia.org/tag/wikimediaui_style_guide/
== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
** 504s in Pageview API RESTBase layer, problem with RESTBase running out
of TCP ports, applying some fixes now to prevent the problem
** notebook1003 is replacing notebook1001, so we need to migrate folks
using Jupyter, watch for communication on the lists
** responsive Wikistats work is ongoing
** porting geowiki to Hadoop is done, building a dashboard on top of it now
** more analytics processes migrated to Kafka Jumbo cluster (webrequest and
EventLogging are fully migrated now)
** improvements on automatic refining of EventLogging topics to Hadoop
* Quarterly goal dependency update:
**Improve, adjust, or create features geared at the needs identified in New
Editors research project.
*** New Editors Experience:Analytics
=== Cloud Services ===
* Blocked by:
* Blocking:
* Updates:
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** Upgrading CiviCRM install to 5.0
** More work on main CC processor new API, including redesigning recurring
contribution charges to fit better with Civi
** Making sure all the unintentional recurring donor refunds happened as
they were supposed to
** More work on using EventLogging to get banner impression and fundraiser
landing page stats
** Looking into applying CSP to banner preview pages, but need to decide
how to make it fit with pending core patch:
https://gerrit.wikimedia.org/r/253969
=== MediaWiki Platform ===
* Blocked by:
* Blocking:
* Updates:
*Quarterly goal dependency update:
** Support work towards unifying MediaWiki's parser implementations, in
liaison with Technology's MediaWiki team
*** Parsing:Mediawiki PF/Services
* Reduce product and technical debt to modernise our tools and
technologies, and to make future changes more effective and efficient
*** Parsing/Mediawiki PF
**1.1 It is possible to store structured data within wiki pages, in
particular on media file pages on Commons. We will enable the MediaWiki
storage layer to correctly store and process structured data elements
within wiki pages.
*** SDC: Mediawiki PF/Wikidata
=== Performance ===
* Blocked by: None
* Blocking: None
* Updates:
** Collecting a bunch of oversample data from countries in Asia/Oceania,
prep for Singapore to go live.
** Thumbor 100% done
** Expecting to spend a bit of time helping with reviews or ResourceLoader
changes related to Hindi wiki front page stuff
** auto_prepend_file being used to load profiler
** Re-did coal changes to use python-kafka, confluent_kafka doesn't work
** Deploying RUMSpeedIndex this week, essentially emulates Speed Index
calculation using the browser resource timing API
=== Release Engineering ===
* Blocking
**
* Blocked
**
* Updates
** Minor Gerrit upgrade planned for this week (2.14.6 -> 2.14.7)
** Incident analysis started last week of the last year’s worth of
incidents reports
** Scap 3.7.7 should be rolled out to production this week
*Quarterly goal dependency update:
** Continue improving the ways that users can download articles of interest
for later consumption
*** Reading Web: Tech Ops/RelEng (work is currently blocked on
https://phabricator.wikimedia.org/T187821 which is part of a larger epic
https://phabricator.wikimedia.org/T181084)
** Talked about in team meeting Monday
** is there a task?
=== Research ===
* Blocked by:
* Blocking:
* Updates:
*Quarterly goal dependency update:
** Wikimedia Technology/Goals/2017-18 Q3#Segment 2: Search integration and
exposure
*** SDC: Research/Multimedia
=== Scoring Platform ===
* Blocked by:
** Releng is helping us with a git-lfs pilot deployment.
** Waiting for Scap 3.7.7 for a fast-rollback process.
* Blocking:
* Updates:
** The JADE extension is in beta.
*** https://www.mediawiki.org/wiki/Extension:JADE
*** This is for auditing ORES. It adds "Jade" and "Jade_talk" namespaces
to MediaWiki. We're using JSON content with schema validation. Prateek is
contributing some volunteer design time.
=== Search Platform ===
* Blocked by:
* Blocking:
* Updates:
*Quarterly goal dependency update:
** Prepare backend infrastructure for structured data search
*** SDC: Search PF/Multimedia/Wikidata
** Update:
*** Trey published new blog about supporting languages with multiple
writing systems:
https://blog.wikimedia.org/2018/03/12/supporting-languages-multiple-writing…
*** AB test for query explorer feature for LTR finished & analyzed:
https://phabricator.wikimedia.org/T189843 Results are looking pretty good,
seems to be improving things.
*** Wikidata search patches merged. The new search not enabled yet, but
improved search result format is.
*** Fixed performance issue with LTR cache:
https://phabricator.wikimedia.org/T188015
*** TermLookup implementation for ElasticSearch merged:
https://phabricator.wikimedia.org/T143706
*** Fixed deepcategory keyword to not return results if keyword has failed,
e.g. because there are too many categories:
https://phabricator.wikimedia.org/T189331
*** Working on query parsing refactoring:
https://phabricator.wikimedia.org/T185108
*** Working on Slovak analysis: https://phabricator.wikimedia.org/T178929
*** Started implementation work on Lexeme search:
https://www.wikidata.org/wiki/User:Smalyshev_(WMF)/Lexeme_search
=== Security ===
* Blocked by:
* Blocking:
* Updates:
=== Services ===
* Blocked by: none
* Blocking: none
* Updates:
** New REST endpoint to get lint errors for page/revision
***
https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_page_lint_title_re…
** New REST endpoint to get page media
***
https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_page_media_title_r…
** refreshLinks topic is now partitioned in kafka according to MySQL
shard, should decrease connection spikiness
=== Site Reliability Engineering ===
* Blocked by:
** None
* Blocking:
** None
* Updates:
** Firewalling of misc database hosts successful. Some delays in OTRS email
delivery experienced
** Consistent logical backups in codfw goal completed successfully
** mathoid deployed in kubernetes. Production traffic is partly served
(~50%) from the new kubernetes cluster in both eqiad+codfw
** eqsin turn-up planning procedure meetings starting.
** EtcdConfig in production goal almost completed
** Some varnish issues ongoing https://phabricator.wikimedia.org/T189892
*Quarterly goal dependency update:
** Continue improving the ways that users can download articles of interest
for later consumption
*** Reading Web: Tech Ops/RelEng
** Update: No updates, was postponed for early next quarter
** Audiences DesignStandardise our user interfaces to match user
expectation of quality from our products
*** Audiences Design: Ops
** Update: Done AFAIK.
== Wikidata ==
* Looking into current Lua usage to see where we can improve the Lua
functions we provide: https://phabricator.wikimedia.org/T189506
* Optimizing a heavily used database table (wb_terms):
https://phabricator.wikimedia.org/T188279
* Polishing a lot of things for lexicographical data first deployment
*Quarterly goal dependency update:
**1.1 It is possible to store structured data within wiki pages, in
particular on media file pages on Commons. We will enable the MediaWiki
storage layer to correctly store and process structured data elements
within wiki pages.
*** SDC: Mediawiki PF/Wikidata
** Prepare backend infrastructure for structured data search
*** SDC: Search PF/Multimedia/Wikidata
== German Technical Wishlist ==
* Blocked on external review for the most recent Wikidiff2 optimizations:
https://gerrit.wikimedia.org/r/404293
* Working towards an MVP of the FileImporter extension:
https://phabricator.wikimedia.org/tag/move-files-to-commons/
* Finishing touches on AdvancedSearch:
https://phabricator.wikimedia.org/tag/advanced-search/
== SoS Meeting Bookkeeping ==
* Updates:
Hi,
As part of auditing MediaWiki initialisation code[1], I noticed the state
of our OutputHandler logic. It is currently implemented through a series of
global functions in a dedicated includes file (separate from
GlobalFunctions.php) which are then ad-hoc loaded (as needed) in
WebStart.php.
I wouldn't consider these part of the public interface, because they were
only conditionally included, and not in any autoloader. Stable usage would
require a consumer to directly require the file from $IP/includes.
However, given that on many wikis they will appear to be consistently
available, it is not impossible someone somewhere might use it somehow.
I found zero callers apart from the primary call in WebStart.php (plus some
Api comments, and a false-positive match in a unit test).
Not usage in MediaWiki core or elsewhere in Wikimedia Git (per
CodeSearch[2] and GitHub[3]).
As such, per our policy [4] I propose to refactor these without leaving
back-compat aliases.
Feedback welcome at https://gerrit.wikimedia.org/r/420223
-- Krinkle
[1] https://phabricator.wikimedia.org/T189966
[2] https://codesearch.wmflabs.org/search/?q=wfOutputHandler
[3]
https://github.com/search?q=org:wikimedia+wfOutputHandler+-repo:wikimedia/m…
[4] https://www.mediawiki.org/wiki/Deprecation#Removal_without_deprecation
I'm refactoring MonoBook, starting with MonoBookTemplate. The current
change gets rid of the entire immediate print/html soup approach and
instead assembles a giant string and prints that in one statement at the
end. See: https://gerrit.wikimedia.org/r/#/c/420154/ and
https://gerrit.wikimedia.org/r/#/c/420161/
Pending reviews and assurances that I have indeed not totally broken
everything, we'll probably be merging this in the next week or so. If
anyone would like to point out particular reasons why this is a terrible
idea, please do so now.
Future plans include putting that ridiculous getPortlet into core
BaseTemplate, making a less dumb BaseTemplate::getFooter without
breaking anything already using it so MonoBook can lose its silly
replication thereof, organising all the files in MonoBook better
(putting them in resources, includes, etc according to standard skin
practices), and making MonoBook responsive.
There are also some problems that need addressing down the road: that
I'm not sure how safe it is for caching and the like to just go moving
images/css files around willy-nilly, that there are no 'standard' skin
practices as far as anyone can tell, and that some people seem to think
MonoBook is bad and not worth this. But MonoBook is not bad. It is a
delightful skin. We should preserve it, and not just in formaldehyde.
-I
Hi there,
I'm a final year Mathematics student at the University of Bristol, and I'm
studying Wikipedia as a graph for my project.
I'd like to get data regarding the number of outgoing links on each page,
and the number of pages with links to each page. I have already
inquired about this with the Analytics Team mailing list, who gave me a few
suggestions.
One of these was to run the code at this link https://quarry.wmflabs.org/
query/25400
with these instructions:
"You will have to fork it and remove the "LIMIT 10" to get it to run on
all the English Wikipedia articles. It may take too long or produce
too much data, in which case please ask on this list for someone who
can run it for you."
I ran the code as instructed, but the query was killed as it took longer
than 30 minutes to run. I asked if anyone on the mailing list could run it
for me, but no one replied saying they could. The guy who wrote the code
suggested I try this mailing list to see if anyone can help.
I'm a beginner in programming and coding etc., so any and all help you can
give me would be greatly appreciated.
Many thanks,
Nick Bell
University of Bristol
What ways are there to include user-edited JavaScript in a wiki page?
I ask because someone put this revision in (which is now deleted):
https://fa.wikipedia.org/w/index.php?title=%D9%85%D8%AF%DB%8C%D8%A7%D9%88%D…
You can't see it now, but it was someone including a JavaScript
cryptocurrency miner in common.js!
Obviously this is not going to be a common thing, and common.js is
closely watched. (The above edit was reverted in 7 minutes, and the
user banned.)
But what are the ways to get user-edited JavaScript running on a
MediaWiki, outside one's own personal usage? And what permissions are
needed? I ask with threats like this in mind.
- d.
Hi,
Sometimes I find adding assert() calls in my code very handy for various
reasons:
- failures in development mode on some complex code where exposing all the
details to unit tests is sometimes hard and/or pointless
- readability of the code
But I worry about the perf implications of these lines of code. I don't
want these assertions to be used to track errors in production mode.
PHP7 introduced expectations which permit to have zero-cost assert() [1]
Looking at the MW codebase we don't seem to use assert frequently (only 26
files [2] ).
Are there some discussions about this?
Is assert() a good practice for the MW code base?
If yes would it make sense to benefit from zero-cost assertions in WMF
appservers?
Thanks!
[1]
http://php.net/manual/en/function.assert.php#function.assert.expectations
[2]
https://codesearch.wmflabs.org/search/?q=%5Ctassert%5C(&i=nope&files=php%24…
[x-posted announcement]
Hello,
Wikimedia Foundation’s Language team would like to invite you for an online
office hour session scheduled for Wednesday, March 21st, 2018 at 13:00 UTC.
This will be an open session to talk about our work, and in particular the
changes to interlanguage links, which were recently rolled-out on the
English Wikipedia.
The new option shows a list of up to 9 languages instead of a long list
that can have more than 200 items, and a panel with all the links that can
be looked up in any language using a search box. The purpose of this
feature is to make articles in all languages easier to find. We recently
published a blog post about this feature and the thoughts behind the
development:
https://blog.wikimedia.org/2018/03/08/compact-language-links-launch.
This session is going to be an online discussion over Google
Hangouts/Youtube with a simultaneous IRC conversation. Due to the
limitation of Google Hangouts, only a limited number of participation slots
are available. Hence, do please let us know in advance if you would like to
join in the Hangout. The IRC channel will be open for interactions during
the session.
Please read below for the event details, including local time, youtube
session links and do let us know if you have any questions.
Thank you
Runa
== Details ==
# Event: Wikimedia Foundation Language office hour session
# When: March 21st, 2018 (Wednesday) at 13:00 UTC (check local time
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20180321T1300)
# Where: and on IRC #wikimedia-office (Freenode) and
https://www.youtube.com/watch?v=RmZcL6zVcTA
# Agenda:
Discussion about Compact Language Links, and Q & A.
--
Engineering Manager, Language (Contributors)
Wikimedia Foundation
Hi all,
TL;DR: When using X-Wikimedia-Debug to profile web requests on Wikimedia
wikis, the generated profile information will now include details from
"w/index.php", and MWMultiVersion, and things like
wmf-config/CommonSettings.php. Details at
https://phabricator.wikimedia.org/T180183.
-
The debug profiler provided on Wikimedia production wikis[1] previously
could not cover the code that executes before MediaWiki core instantiates
ProfilerXhprof, which was in charge of calling `xhprof_enable`. This
normally happens within core's Setup.php.
While that point in Setup.php is before any important MediaWiki core logic,
it misses out on two other chunks of code:
1. Initialisation of MediaWiki core – This includes entry point code (eg.
index.php, PHPVersionCheck), but also the first steps of Setup before
Profiler. Such as AutoLoader, vendor, and LocalSettings.php. At WMF,
LocalSettings.php loads wmf-config/InitialiseSettings.php and
wmf-config/CommonSettings.php.
2. Wrapping of MediaWiki entrypoint – At Wikimedia, the index.php
entrypoint is itself further wrapped in something called "multiversion".
Multiversion is what determines the wiki ID (eg. "enwiki") and MediaWiki
branch (eg. "1.31.0-wmf.25") associated with the current domain (eg. "
en.wikipedia.org").
Over the past weeks, I've been refactoring MediaWiki core, wmf-config and
Wikimedia's HHVM settings to make we can instrument the above code as part
of our performance profiles.
This change happened in three phases:
## 1. Update wmf-config/StartProfiler to.. actually start the profiler!
The file name is somewhat deceptive because traditionally this is (and can)
only be used to *configure* the profiler, by assigning $wgProfiler. It
makes sense that we cannot instantiate the Profiler subclass from this
file, because the classes and run-time configuration are not and cannot be
available this early.
However, we don't the Profiler class to record data. The Profiler classes
typically obtain their data from native PHP. The one used at WMF is XHProf.
Previously, we would assign $wgProfiler['class'] = 'ProfilerXhprof', and
then later MediaWiki core instantiates ProfilerXhprof, which then calls
xhprof_enable. We now xhprof_enable directly from StartProfiler.php.
This change enabled coverage of code in Setup.php between 'include
StartProfiler' and 'Profiler::instance()'. – Mainly: vendor, LocalSettings,
wmf-config.
## 2. Update MediaWiki core to include StartProfiler earlier.
It is now the first thing included by Setup.php.
This change enabled coverage of code in Setup.php that previously was
before 'include StartProfiler'. – Namely: AutoLoader.php, Defines.php.
## 3. Configure WMF's PHP engine to use auto_prepend_file
This is the big one, and requires a PHP ini setting change. Third parties
can follow the same pattern
in order to get the same benefits:
* Put `xhprof_enable( $flags )`, along with any sampling/conditional
logic, in a separate file.
* Use it from two places:
** In StartProfiler.php, include using require_once.
** In php.ini, set auto_prepend_file=path/to/profiler.php.
This change enabled coverage of all remaining code. – Namely: multiversion,
w/index.php and things like PHPVersionCheck.
## Example
Using cURL:
$ curl -H 'X-Wikimedia-Debug: 1' 'https://en.wikipedia.beta.
wmflabs.org/w/load.php?debug=false&modules=startup&only=
scripts&forceprofile=1'
Output now includes:
- main() # resembles the wrapper at
operations/mediawiki-config.git:/w/load.php
-- run_init::/srv/mediawiki/multiversion/MWMultiVersion.php
-- MWMultiVersion::getMediaWiki
-- run_init:/srv/mediawiki/php-../load.php
-- run_init::/srv/mediawiki/php-../includes/Setup.php
-- run_init::/srv/mediawiki/php-../LocalSettings.php
-- run_init::/srv/mediawiki/wmf-config/CommonSettings.php
--
run_init::/srv/mediawiki/php-../extensions/Wikibase/client/WikibaseClient.php
Greetings,
-- Timo Tijhof
[0] https://phabricator.wikimedia.org/T180183
[1] https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug
*On 14 March 2018, evidence of cryptocurrency mining software was
discovered on Persian Wikipedia. It was identified by the community and
removed within 10 minutes of being added to the site. Additionally, the
rights of the user responsible have been revoked and their account has been
globally locked. At this time there is no evidence of any user's computer
or account being compromised or otherwise affected. However, we encourage
everyone to take some routine steps to maintain a secure computer and
account - including regularly changing your passwords, actively running
antivirus software on your systems, and keeping your system software up to
date. The Wikimedia Foundation's Security team is investigating this
incident as well as potential improvements to prevent future incidents. If
you have any questions, please contact the Security team
(security-team{{(a)}}wikimedia.org <http://wikimedia.org/>). Apologies for
only posting in English, translating and reposting in Fārsi would be
greatly appreciated.Thanks,John Bennett*
https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-03-14
= 2018-03-14 =
= date =
== Callouts ==
* Fundraising campaigns
https://meta.wikimedia.org/wiki/CentralNotice/Calendar - next up:
Netherlands 2018-04-03 through 2018-05-01
* [Performance] Editing: Someone familiar with VisualEditor should probably
take a look at https://phabricator.wikimedia.org/T189229-- perf issue, but
not something that we can easily address
* [Language] SRE: DBA to look/review:
https://phabricator.wikimedia.org/T187986
* [SRE] Started talking about next Quarter's goals, please DO LET us know
if you have dependencies on us, don't just mark them on the wiki.
* Tidy has been replaced on another 100 wikis this week. About 300 more to
go before the end June deadline.
* https://gerrit.wikimedia.org/r/#/c/415770/ is almost ready to go that
implements RFC to trim whitespace in headings, lists, and table cells. Very
likely to go out next week unless there are objections raised in the last
call period (ending today, I think).
* Parsing team has been working on the heredocs syntax RFC (
https://phabricator.wikimedia.org/T114432 ) and has a WIP patch @
https://gerrit.wikimedia.org/r/#/c/418198/ if someone wants to test and
play with it on your local dev wikis.
* Wikistats 2 has now a canary site - https://wikistats-canary.wmflabs.org/
* 1.31.0-wmf.25 going out this week, if you see blockers:
https://phabricator.wikimedia.org/T183964
* Scoring platform team is restarting work on the promotional editing
model, want to collaborate?
== Audiences ==
=== Readers ===
==== iOS native app ====
* Blocked by:
* Blocking:
* Updates:
**
==== Android native app ====
* Blocked by:
* Blocking:
* Updates:
** Continuing rollout of Reading List syncing to Beta audience. Wrapping up
next maintenance/bugfix release.
==== Readers Web ====
* Blocked by:
Language engineering/core platform(?) -
https://gerrit.wikimedia.org/r/#/c/415187/ We'd like to make RTL info of
languages available cheaply either via JavaScript/PHP array or API.
Guidance needed
* Blocking:
* Updates:
Refreshing some old bugs relating to the Nearby overlay
*Quarterly goal dependency update:
** Increase learning by lowering the cost of exploration
*** On final stretch. Aiming to launch previews within next 3 weeks. Now we
have the new summary endpoint from RI we are addressing some legacy code on
client.
*** Reading Web/Performance
** Continue improving the ways that users can download articles of interest
for later consumption
*** Reading Web: Tech Ops/RelEng
==== Readers Infrastructure ====
* Blocked by:
* Blocking:
* Updates:
** Filter for /page/summary endpoint is enabled, which means all reads
should get the latest version. If you find any issues with the summary
content please file a task.
** Wikidata overrides will be enabled on beta enwiki today (Wed), testwiki
early next week
===== Maps =====
* Blocked by:
* Blocking:
* Updates:
**
==== Multimedia ====
* Updates
** 3D work closing soon
** Work on file page prototype for structured data is progressing (slowly),
may be bothering WMDE soon about some questions
** Search work seems like it's going smoothly, thanks Search for being
available and helpful
** UploadWizard prototype changes for multi-lingual captions
Quarterly goal dependency update
** Prepare backend infrastructure for structured data search
*** SDC: Search PF/Multimedia/Wikidata
** Wikimedia Technology/Goals/2017-18 Q3#Segment 2: Search integration and
exposure
*** SDC: Research/Multimedia
** Prepare backend infrastructure for structured data search
*** SDC: Search PF/Multimedia/Wikidata
=== Contributors ===
==== Community Tech ====
* Blocked by: SRE on GlobalPreferences schema T184666 - quarterly goal
* Blocking:
* Updates:
** Working on thanking for log entries and squashing some CodeMirror bugs
before promoting it from beta feature.
==== Anti-Harassment Tools ====
* Blocked by: None
* Blocking: None
* Updates:
** Compmleted Interaction Timeline v1
** Started work on blocking tools
** Research for reporting system
==== Editing ====
* Blocked by:
* Blocking:
** Updates:
==== Parsing ====
* Blocked by:
* Blocking:
* Updates:
** We've fallen behind responding to all the Linter feature requests --
since we don't have sufficient time to handle all of it, but we'll try to
address some in the coming couple weeks.
** Tidy has been replaced on another 100 wikis this week. About 300 more to
go before the end June deadline.
** https://gerrit.wikimedia.org/r/#/c/415770/ is almost ready to go that
implements RFC to trim whitespace in headings, lists, and table cells. Very
likely to go out next week unless there are objections raised in the last
call period (ending today, I think).
** Arlo has been working on the heredocs syntax RFC (
https://phabricator.wikimedia.org/T114432 ) and has a WIP patch @
https://gerrit.wikimedia.org/r/#/c/418198/ if someone wants to test and
play with it on your local dev wikis.
** Scott has been adding language variant conversion support to Parsoid --
a WIP patch in place for Serbian.
** Arlo would appreciate Android app folks taking a look at
https://gerrit.wikimedia.org/r/#/c/411493/ -- this is not directly related
to Parsing work.
*Quarterly goal dependency update:
** Support work towards unifying MediaWiki's parser implementations, in
liaison with Technology's MediaWiki team
*** Parsing:Mediawiki PF/Services
*** No new updates or blockers.
==== Collaboration ====
* Blocked by: nobody
* Blocking: nobody
* Updates:
** Working on a test setup for the maps services (Kartotherian and
Tilerator) in beta labs, to replace the maps-test servers
==== Language ====
* Blocked by: See callouts.
* Blocking:
* Updates:
** CX2 (ie ContentTranslation version 2 with VE) work continue.
=== Audiences Design ===
* Blocked by:
* Blocking:
* Updates:
**
* Quarterly goal dependency update:
** Audiences DesignStandardise our user interfaces to match user
expectation of quality from our products
*** Audiences Design: Ops
==== UI Standardization ====
* Blocked by: Security review for Style Guide
https://phabricator.wikimedia.org/T188698
* Blocking:
* Updates:
** OOUI – no release this week, in prep for v0.26.0 breaking change release
with (currently planned)
*** WikimediaUI theme's new icon set
https://gerrit.wikimedia.org/r/#/c/400091/
*** Aligning VE and Special:Pages interface base font-size to each other
https://phabricator.wikimedia.org/T97631
*** Switch to grunt-svgmin for SVG opt accomplished
** Style Guide
*** Continued work to accomplish v1 goals
https://phabricator.wikimedia.org/tag/wikimediaui_style_guide/
== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
** Eventlogging Analytics migrates to Kafka Jumbo -
https://phabricator.wikimedia.org/T183297
** Eventlogging is now on eventlog1002 and running Debian/systemd
** Deployed sanitization efforts on EventLogging Hive
https://phabricator.wikimedia.org/T181064
** Wikistats 2 has now a canary site - https://wikistats-canary.wmflabs.org/
** Rolling out responsive site soon
* Quarterly goal dependency update:
**Improve, adjust, or create features geared at the needs identified in New
Editors research project.
*** New Editors Experience:Analytics
=== Cloud Services ===
* Blocked by:
* Blocking:
* Updates:
** Wikitech moved to new labweb hardware
https://phabricator.wikimedia.org/T168470
** Updates to Horizon and Toolsadmin coming up on Wednesday, Mar 15
*** Horizon UI will look different - test it out at
https://newhorizon.wikimedia.org/
** Dumps dataset server migration being planned for first week of April
*** See https://phabricator.wikimedia.org/T168486#4033572 for timeline
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** CentralNotice: deployed and announced security patches, now deploying
EventLogging for impressions. Reviewing a couple of contributed patches.
** CiviCRM: working on anti-fraud tools and custom imports
** More work for main card processor's new API
** Working to also use EventLogging for fundraiser landing page hits
=== MediaWiki Platform ===
* Blocked by:
* Blocking:
* Updates:
** Edit summary display-side truncation
https://gerrit.wikimedia.org/r/#/c/417593/
** Sifting through resumes
** Coordinating with Federal MediaWiki user group and User:Econterms on VPAT
*** User:Econterms has started
https://www.mediawiki.org/wiki/VPAT_for_MediaWiki
** Published aggregate pingback data at https://pingback.wmflabs.org
** Started working on patches to extensions to use Actor table
** RemexHtml parser tests merged https://gerrit.wikimedia.org/r/#/c/409432/
** PHP 7.0 MediaWiki unit tests now voting
https://gerrit.wikimedia.org/r/#/c/417343/
*Quarterly goal dependency update:
** Support work towards unifying MediaWiki's parser implementations, in
liaison with Technology's MediaWiki team
*** Parsing:Mediawiki PF/Services
**** No new updates or blockers
*** Parsing/Mediawiki PF
**** No new updates or blockers
*** SDC: Mediawiki PF/Wikidata
**** No new updates or blockers
=== Performance ===
* Blocked by:
** n/a
* Blocking:
** n/a
* Updates:
** Issues with the kafka library that we used for upgrading coal (one of
our utilities), need to re-do
** We will start working on safemode for Visual Editor this week
** Attempting to remove a few query-master-on-GET issues
** Updated our MediaWiki profiling to start earlier, will catch more
performance issues on startup
** Beginning to work on packaging Dynomite
** Oversampling of performance data in Singapore is live
=== Release Engineering ===
* Blocking
** Scoring platform release of scap 3.8 (I think mukunda tagged that, but
I'll double check)
* Blocked
** SRE: Minikube packaging stuff https://phabricator.wikimedia.org/T184457
* Updates
** 1.31.0-wmf.25 going out this week, if you see blockers:
https://phabricator.wikimedia.org/T183964
** greg is out this week, FYI
*Quarterly goal dependency update:
** Continue improving the ways that users can download articles of interest
for later consumption
*** Reading Web: Tech Ops/RelEng
** Update:
*
=== Research ===
* Blocked by:
* Blocking:
* Updates:
*Quarterly goal dependency update:
** Wikimedia Technology/Goals/2017-18 Q3#Segment 2: Search integration and
exposure
*** SDC: Research/Multimedia
** Update:
*
=== Scoring Platform ===
* Blocked by: RelEng on release of scap 3.8 and git-lfs
* Blocking:
* Updates:
**Extension:JADE is live on the beta cluster :D
** wp10 model support in ORES ext. is almost finished. Expected to have it
enabled in enwiki next week
**Restarting work on the promotional editing model, want to collaborate?
***Just about to publish a dataset of paid editors
=== Search Platform ===
* Blocked by:
* Blocking:
* Updates:
** Testing “query explorer” feature of LTR plugin:
https://phabricator.wikimedia.org/T187148
** TermLookup implementation for ElasticSearch ready for review:
https://phabricator.wikimedia.org/T143706
** Working on query parsing refactoring:
https://phabricator.wikimedia.org/T185108
** Serbian analyzer merged, will be enabled after Elastic plugin is
deployed: https://phabricator.wikimedia.org/T183015
** Next is Slovak analysis: https://phabricator.wikimedia.org/T178929
** Discussing Lexeme search:
https://www.wikidata.org/wiki/User:Smalyshev_(WMF)/Lexeme_search
** Stability issues with wdqs1004 solved (thanks RobH and all who helped!),
WDQS cluster back at full capacity
** Kafka poller has been having problems, had to turn off for now. Will be
back when jumbo mirroring is stable -
https://phabricator.wikimedia.org/T189458
*Quarterly goal dependency update:
** Prepare backend infrastructure for structured data search
*** SDC: Search PF/Multimedia/Wikidata
**** Working with Cormac on MediaInfo/File indexing patch
****Started design discussions on Lexeme search -
https://www.wikidata.org/wiki/User:Smalyshev_(WMF)/Lexeme_search
** Update:
*
=== Security ===
* Blocked by:
* Blocking:
* Updates:
**
=== Services ===
* Blocked by: none
* Blocking: none
* Updates:
** Summary migration completely complete
** Working on issues with MySQL connection spiking from refreshLinks jobs an
d kafka rebalancing issues
=== Site Reliability Engineering ===
* Blocked by:
** None
* Blocking:
** None
* Updates:
* Started talking about next Quarter's goals, please DO LET us know if you
have dependencies on us, don't just mark them on the wiki.
**
*Quarterly goal dependency update:
** Continue improving the ways that users can download articles of interest
for later consumption
*** Reading Web: Tech Ops/RelEng
** Update: No updates
*
** Audiences DesignStandardise our user interfaces to match user
expectation of quality from our products
*** Audiences Design: Ops
** Update: No updates on our side, ball is not in our field.
== Wikidata ==
* Blocked by: nothing
* Blocking: not aware of any blocks
* Updates: re-org happened, we are now 2 teams, so didn't achieve much as
far as production in the last week, Team 1 will focus on delivering Lexeme
and team 2 are working on Scalaibity issues and data quality at this point
**
*Quarterly goal dependency update:
**1.1 It is possible to store structured data within wiki pages, in
particular on media file pages on Commons. We will enable the MediaWiki
storage layer to correctly store and process structured data elements
within wiki pages.
*** SDC: Mediawiki PF/Wikidata
** Update:
*
** Prepare backend infrastructure for structured data search
*** SDC: Search PF/Multimedia/Wikidata
** Update:
*
== German Technical Wishlist ==
* Blocked by:
** Review on https://gerrit.wikimedia.org/r/#/c/404293/
* Blocking:
** no
* Updates:
** continue working on FileImporter
** Finished work on Wikidiff2 (Reviewww!!)
** Continue working on AdvancedSearch
== SoS Meeting Bookkeeping ==
* Updates:
**