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



Lots of people, about 12 permanent staff.

On going responsibilities[edit]

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


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


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

ON GOING[edit]


  • 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[edit]

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


  • 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)[edit]

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

DevOps Sprint[edit]

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

Wikimania Scholarships app[edit]

  • 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[edit]

  • 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)


  • 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



  • 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[edit]

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


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

central code repo[edit]


  • 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
  • <huge discussion of huge community/political impacts here>
    • "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[edit]

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

gerrit improvements[edit]

  • eg BZ integration

Other topics?[edit]