Wikimedia Platform Engineering/MediaWiki Core Team/Quarterly review, October 2013/Notes
< Wikimedia Platform Engineering | MediaWiki Core Team | Quarterly review, October 2013(Redirected from Wikimedia MediaWiki Core Team/Quarterly review, October 2013/Notes)Jump to navigation Jump to search
Lots of people, about 12 permanent staff.
On going responsibilities
- MW ops things
- Code reviews
- 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
- 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.
- 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)
- doing almost-weekly RFC IRC meetings
- the Architecture Summit is coming up in January
- 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
- 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
AS TIME ALLOWS
- 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
This projects have been postponed merely to let us handle the projects above.
central code repo
- 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?
- 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?
- ACTION: one thing to get done this quarter is to have an RFC written in time for the Arch Summit in January
- eg BZ integration
- 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
- start experimenting with what a tablet view of the site would look like