Wikimedia Platform Engineering/MediaWiki Core Team/Quarterly review, October 2013/Notes

Team
Lots of people, about 12 permanent staff.

On going responsibilities

 * deploys
 * MW ops things
 * Code reviews
 * Security
 * Test
 * Git/gerrit
 * Shell
 * we rely on features for glamour

SUL

 * improvements/changes to Fx and other browser would break our previous implementation of SUL
 * Finished in Sept

SSL

 * unplanned work, including work from Ops (eg Ryan)
 * This was SSL by default for logged-in users

OAuth

 * provides limited authentication to labs/mobile/etc apps
 * Almost done, ran over schedule due to a few reasons
 * classic under esitmation of time required
 * too much on Chris' shoulders
 * ACTION: will review our assignment process in the next quarter to make sure this doesn't happen again
 * are deployed on the test wikis (eg: test, test2, mediawiki)
 * two labs projects are actively implementing OAuth right now
 * waiting on UX sign off before rolling out further (to all wikis)
 * longer term issues to work on, but a good MVP (Minimum Viable Product) is pretty close to go out
 * is the language of the rights transaction a part of the UX review?
 * should be close to finalized, but there is still room for improvement
 * give any more design/UI feedback to Dan G and May.

Security audit/response

 * always on going
 * Code review:
 * Limn, TimedMediaHandler v2, Kraken, GLAM
 * past includes the password reset/expiration work

Search

 * Deploying ElasticSearch out to our cluster
 * on a few (small) wikis so far
 * ahead of schedule
 * ACTION: blocked on Ops review on review of setup + hardware allocation (mark)

Architecture (RFC)

 * doing almost-weekly RFC IRC meetings
 * the Architecture Summit is coming up in January

DevOps Sprint

 * Next quarter
 * improve the robustness of our infra (monitoring, reporting, and git-deploy)

Wikimania Scholarships app

 * a couple thousand lines of code to review and run on our cluster for scholarship management
 * hard deadline of December
 * has been on roadmap for a while, but the scope of work has expanded
 * audit in lieu of rewrite would probably be the most efficient method
 * this is a stand-alone app, not an extension, so where should this live?
 * ACTION: Work with Ops on location (any misc server?)
 * Long term this should be its own project and rewritten to include registration generally as well
 * ACTION: look at existing FLOSS solutions? nothing inspiring last time a review was done
 * Chad is doing this

Auth Systems

 * labsdb 'fallout', but good time to reprioritize
 * proper password expiration system
 * improving password hashing/encryption
 * expecting to review OpenID volunteer code this quarter
 * did do a review this past quarter
 * wasn't working with $wgSecureLogin, and barfs against mixed http/https environment
 * one potential direction with OAuth is OAuth2OpenID Connect (what FB uses)

Performance

 * yay Ori!
 * starting with a performance audit
 * in doing so, building developer tools that raise visibility of performance
 * interpreting/publicizing navigation timing data
 * profiling of front-end code
 * work with product/analytics to correlate site performance with editor engagment data, to articulate the value of performance/infra work
 * note on graphite being in need of major help

HipHop

 * will have a heavy ops component, and they are focused on eg db migration/setup
 * but we don't know how much longer we have with FB's outwardly interest
 * try to do some smaller thing with hhvm, eg localization cache generation
 * 2 things to work wrt hhvm: porting and running tests against mw on hhvm
 * would be nice to have a hhvm env in beta labs
 * replace current apache config with all the diff vhosts with something along the lines of hhvm?
 * stll have php extensions that need to be ported, many just ours, a couple upstream
 * wmerror/faststringsearch could be implemented in pure php to run against hhvm

Admin Tools sprint

 * with Dan now on board, we have capacity to manage this list/work/priorities better

DEFERRED
This projects have been postponed merely to let us handle the projects above.

central code repo
lua+gadgets+javascript
 * Code Review of code on wiki (eg localsite.css)
 * proposal to have a code review step for these files?
 * what would the review process look like (community team working on this)?
 * what would the technical implementation look like?
 * we need to think about the security concerns of small/quick changes to wiki-wide javascript
 * is there a way to address the code review of wiki-wide js without making it a part of a central code repo?
 * could just integrate gadgets/js auto pulled out of git, with code review in gerrit
 * 
 * "issues that are political won't be solved by technical means"
 * community buy-in to doing the central code repo would be positive
 * QUESTION: what is the full problem space here? what is the one part of it that we could submit resources to in one quarter?

configuration database

 * ACTION: one thing to get done this quarter is to have an RFC written in time for the Arch Summit in January

gerrit improvements

 * eg BZ integration

Other topics?

 * gwicke: Cassandra for external storage, heads up -- see https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage & https://github.com/gwicke/storoid, also cf. https://www.mediawiki.org/wiki/Requests_for_comment/DataStore
 * why use cassandra: compression, scalability
 * why not h-base? slower, not as well with failover
 * mobile
 * start experimenting with what a tablet view of the site would look like