MediaWiki

Scrum of scrums/2018-10-03

< Scrum of scrums

2018-10-03

edit

Callouts

edit

Switchover/Switchback dates reminder. It's next week!

Switchback:

Traffic: Wednesday, October 10th 2018 09:00 UTC MediaWiki: Wednesday, October 10th 2018: 14:00 UTC Services: Thursday, October 11th 2018 14:30 UTC Media storage/Swift: Thursday, October 11th 2018 15:00 UTC

  • Release Engineering
    • Next week: No train next week, DC switchover
  • Reading Infrastructure:

We would like to ask the Security Team how is the security review of "JsonConfig and Kartographer interaction" (T163827) going and if they need any help with that (It's not blocking anything, but we would like to know the current status)

  • Parsoid

Services (Core Platform) and Parsing team deployed code this week that implements HTML version (content) negotiation protocol alongwith a major version bump of Parsoid HTML from 1.8.0 to 2.0.0 ( https://www.mediawiki.org/wiki/Specs/HTML/2.0.0 ). As part of this, RESTBase + Parsoid will enforce the HTML version requested in the Accept header. If a version is requested that is different (^ semantics) than what is available in storage, RESTBase will ask Parsoid to get the appropriate version. If Parsoid cannot do that, it will return a HTTP 406. What does it mean for Parsoid clients? If you are requesting a really old version in your Accept header, you are very likely going to get a HTTP 406. If you request an older version (1.7 or 1.8), you will see an additional latency to your requests while Parsoid downgrades the HTML from the more up to date version. So, Parsoid clients should provide an accept header with the most up-to-date version of Parsoid HTML you can handle. Subsequently, you should update your code to handle the newer versions in a timely manner. A longer announcement and wiki docs will be coming out soon.


Audiences

edit

Contributors

edit

Community Tech

edit
  • Blocked by:
  • Blocking:
  • Updates:

Anti-Harassment Tools

edit
  • Blocked by:
  • Blocking:
  • Updates:

Editing

edit
  • Blocked by:
  • Blocking:
    • Updates:

Growth

edit
  • Blocked by:
  • Blocking:
  • Updates:

Language

edit

Readers

edit

iOS native app

edit
  • Blocked by:
  • Blocking:
  • Updates:

Android native app

edit
  • Blocked by:
  • Blocking:
  • Updates:


Readers Web

edit
  • Blocked by:
  • Blocking:
  • Updates:
    • Mobile website (MinervaNeue / MobileFrontend):
      • Maintenance and bug fixes T205449 T202756
    • SEO: where should Schema property 'sameAs' live? T204070
      • The Performance team is going to be deploying a second set of sitemaps next week, they will also be testing the indexing on mobile in parallel. Mikhail has analyzed the data from the initial Italian sitemap launch and we haven't seen any conclusive evidence that they've helped referrals or increased pageviews. We will repeat the analysis with the other wikis.
    • Management supporting Multimedia hiring processes
    • Product working on 3-5 year planning


Readers Infrastructure

edit


Multimedia

edit
  • Updates

Parsing

edit
  • Blocked by:
  • Blocking:
  • Updates:
   Services (Core Platform) and Parsing team deployed code this week that implements HTML version (content) negotiation protocol alongwith a major version bump of Parsoid HTML from 1.8.0 to 2.0.0 ( https://www.mediawiki.org/wiki/Specs/HTML/2.0.0 ). As part of this, RESTBase + Parsoid will enforce the HTML version requested in the Accept header. If a version is requested that is different (^ semantics) than what is available in storage, RESTBase will ask Parsoid to get the appropriate version. If Parsoid cannot do that, it will return a HTTP 406. What does it mean for Parsoid clients? If you are requesting a really old version in your Accept header, you are very likely going to get a HTTP 406. If you request an older version (1.7 or 1.8), you will see an additional latency to your requests while Parsoid downgrades the HTML from the more up to date version. So, Parsoid clients should provide an accept header with the most up-to-date version of Parsoid HTML you can handle. Subsequently, you should update your code to handle the newer versions in a timely manner. A longer announcement and wiki docs will be coming out soon.

UI Standardization

edit

Technology

edit

Analytics

edit
  • Blocked by:
  • Blocking:
  • Updates:

Cloud Services

edit
  • Blocked by:
  • Blocking:
  • Updates:

Fundraising Tech

edit
  • Blocked by:
  • Blocking:
  • Updates:
    • Big English mass emails have begun! Watching for errors and trying to keep donation infrastructure solid
    • Debugging some CI issues with CiviCRM
    • Following along with core and/or language teams' work on CentralNotice save slowness
    • Support for Endowment Gifts via donations pipeline
    • Fixing audit file downloads

MediaWiki Core Platform

edit
  • Blocked by:
  • Blocking:
  • Updates:
    • Deployed content negotiation for Parsoid ( https://phabricator.wikimedia.org/T128040 )
      • result of a 2 1/2 year collaboration with Parsing
      • allows clients to request a specific version of the content-type (how the content would look if produced by a specific version of the software)
    • PHP7 profiler development work
    • Tech Conf session design


Performance

edit
  • Blocked by:
  • Blocking:
  • Updates:
    • Identified performance issue with saving banners due to RevisionStore, working with several teams on a fix
    • Added some additional data points to NavTiming collection
    • Chrome 69 shows a regression in firstPaint, reported upstream
    • Investigating a memory leak in our front-end code: https://phabricator.wikimedia.org/T205127
    • Investigating memcache TKOs: https://phabricator.wikimedia.org/T203786
    • Actively working to eliminate ongoing messages from the mediawiki-errors logging channel. Your team may be tagged on those, please take a look if/when you are.

Release Engineering

edit

Research

edit


Scoring Platform

edit
  • Blocked by: None
  • Blocking: None
  • Updates:
    • Working on improving logging and send more logs to logstash

Search Platform

edit

Security

edit


Services

edit
  • Blocked by:
  • Blocking:
  • Updates:


Site Reliability Engineering

edit
  • Blocked by:
    • None
  • Blocking:
    • None
  • Updates:
    • Switchback to eqiad happening next week, no train, only emergency deploys

Wikidata

edit
  • Blocked by:
  • Blocking:
  • Updates:

German Technical Wishlist

edit
  • Blocked by:
  • Blocking:
  • Updates:

Multi-Content Revisions

edit
  • Blocked by:
  • Blocking:
  • Updates:
    • "read new" enabled on mediawiki.org on Monday
    • "read new" will be enabled on commons on October 15
    • "read new" may be enabled on several small/medium wikis in the interim
    • addressing gaps and regressions and beginning to address tech debt

SoS Meeting Bookkeeping

edit
  • Updates:
Retrieved from "https://www.mediawiki.org/w/index.php?title=Scrum_of_scrums/2018-10-03&oldid=4024178"