Wikimedia Platform Engineering/MediaWiki Core Team/Quarterly review, October 2014

Library infrastructure for MediaWiki
Breaking up pieces of MediaWiki's monolithic core into libraries, and generally making it easier to extract pieces from MediaWiki. Continue the work started with the introduction of Composer managed dependencies by extracting library code from includes/libs and elsewhere. CSSJanus, CSSMin, ResourceLoader
 * How interested are we in taking this on?
 * This seems to have the most enthusiasm in the group so far
 * How does it align with the goals of the organization?
 * Makes contributing to MediaWiki easier
 * Makes pluggable implementations (services) easier
 * How does it align with other team's commitments?
 * (fill me in)
 * How urgent is it?
 * It depends how eager we are to split up MediaWiki core into multiple components and to have the option to turn those components into independent, efficient web services.
 * Where does "web services" come in with many of these? Do we really want the overhead of a web service for generating UUIDs or parsing JSON?
 * I think the mention of "web services" came from things I was saying in the meeting about encapsulating things behind well-defined interfaces which opens up the possibility of multiple implementations. One straw man example I gave in an email was " swap storage of revisions as exists now with some system that has better performance characteristics for the Wikipedia wiki farm". This sort of thing would not be on my personal first steps roadmap for the project but a longer term goal. --BDavis (WMF) (talk) 19:35, 22 September 2014 (UTC)
 * What other project(s) would doing this unblock?
 * Core is unambiguously the only team for which this is in-scope. Initial work done by Core can show others how to approach this issue. There is interest in other groups as well (Editing, Flow) that are eager to be able to package work integrated in core in such a way as to make it discoverable via Composer, and hope this is a step toward making it easier and generally more acceptable to pull in libraries from elsewhere.
 * Values:
 * Help with recruitment -- both by making it easier to ramp up as a contributor, and by making our work more visible (because more generic)

Performance metrics
Concrete deliverable:
 * Instrumentation of VE?
 * Much of this is done.  Timing data is being emitted from ...
 * http://gdash.wikimedia.org/dashboards/ve/
 * https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/master/modules/ve-mw/init/ve.init.mw.TargetEvents.js
 * https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/modules/ext.wikimediaEvents.ve.js
 * Needs
 * Rigorous definition of what needs to be tracked
 * Correlation of changes in code to changes in performance
 * Milestone:
 * Weekly report sent out automatically from the system that is interesting, clear and actionable
 * How interested are we in taking this on?
 * How does it align with the goals of the organization?
 * 2014-2015 Engineering goal: "Understand, measure, and monitor readership across projects."
 * How does it align with other team's commitments?
 * TechOps wants to make metrics a priority for the coming quarter, so there's opportunity for collaboration there.
 * How urgent is it?
 * What other project(s) would doing this unblock?

Dependency injection/Setup.php
This project would involve establishing a precedent for using dependency injection in Setup.php, and having lazy initialization generally. This would clean up many messes; for example, user initialization is a mess because of the way things currently work.


 * How interested are we in taking this on?
 * Insofar as it's necessary for librarization (see above), very. We would likely need to do something like this for libraries to make sense.  However, it may not be necessary to do everything at once to succeed in establishing best practices for busting modules out into libraries.
 * How does it align with the goals of the organization?
 * (fill me in)
 * How does it align with other team's commitments?
 * (fill me in)
 * How urgent is it?
 * (fill me in)
 * What other project(s) would doing this unblock?
 * (fill me in)

A/B testing

 * How interested are we in taking this on?
 * Fairly.
 * How does it align with the goals of the organization?
 * Per https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals, the high-level goals for Engineering are "Maintain Total Active Editors at end-of-year levels (0% year-over-year decline)" and "Understand, measure, and monitor readership across projects."
 * How does it align with other team's commitments?
 * Both Analytics and Product are interested in this.
 * corollary: if we don't do it, Analytics (or one of the Feature teams) might.
 * How urgent is it?
 * Reasonably urgent.
 * What other project(s) would doing this unblock?
 * Mobile Web would like to do some proper A/B testing next quarter for the WikiGrok project.
 * Alignment
 * aligns with Analytics and Product goals
 *  "Developers integrate PlanOut by defining experiments that detail how units (e.g., users, cookie IDs) should get mapped to parameters that control the user experience."
 * https://www.facebook.com/download/255785951270811/planout.pdf

Secondary projects

 * Search result optimization - there's a lot of work that can be done to improve our search results, especially in the case of misspellings and thinkos. Once we get ElasticSearch deployed, an important next step will be to make it better.