Scrum of scrums/2018-10-03

From mediawiki.org

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"