Mobile web/Etherpad/2013-2014 Q2 Mobile web meetings

2013-2014 Q2 Mobile web discussions, 19 September 2013

Agenda

 * Quarterly retrospective
 * Brainstorm topics for discussion
 * Discussion about deployments
 * Discussion about QA/code coverage
 * Discussions around top brainstormed topics

What worked?

 * We have Echo, Editing and all sorts of things yey!
 * bingle
 * naming iterations
 * Kenan and Maryana's transition :)
 * trolling arthur+++
 * Arthur's month long vacation didn't seem to have a huge negative impact (except for making it harder to get code review for Max)
 * Taking care of many bugs
 * HTMLFormatter stuff
 * Responding well to bugs - could be even clearer
 * Good data instrumentation
 * Strong excitement across org
 * Remote work support
 * Now have more people who can deploy (+documentation)
 * volunteer patch! \o/

What didn't?

 * visibility of alpha/beta features - some we just forgot about - Alpha as a place for features to bitrot+++++++ [Jon]
 * bingle could do more for me - resolving duplicates, backlogging enhancements, transitions +++ [Arthur]
 * Didn't QA editing across projects - generally QA'ing across many projects that are not enwiki +++ [Michelle]
 * communicating with ops / cross team working +++ [Arthur/Erik M]
 * Documentation is hard to find [Kaldari]
 * Bugs that are actually stories++
 * lost momentum with Wikimania / All staff - lots of collaboration happened though +
 * felt a bit overloaded by design discussions + ^ (same as above?)
 * some lower priority but important code maintenance patches rotted/died (minerva, ajax page loading alpha)
 * writing stories for the sake of stories
 * certain stories felt like they could only be achieved by Max which is somewhat worrying
 * our velocity graphs look totally f'd+
 * Could've fixed more bugs +
 * Could get even better abour communicating to rest of org

What still puzzles us?

 * How screwed are we if Max gets sick? get Arthur to do less scrum mastery:P
 * how do we solve the thank trolling problem
 * Should all features put into beta have eventlogging built in as a precondition
 * How do we attract more volunteer developers
 * if we wontfix something how we can stop someone from reopening it..?!
 * Features in alpha, beta, promoted to stable
 * Browser support +++

Agenda brainstorm

 * Browser support / die WAP die++++++
 * Performance is a feature++++++
 * Moving more code to core (less custom code)+++++
 * Involving the community more++
 * Alpha / Beta+

Browser support

 * WAP support on site, but we spend no dev time on it and do not test it
 * bug today about popular WAP browser not supporting proto-relative URLs
 * Max wants to drop WAP support
 * Need updated #s for Zero WAP usage
 * Current WAP detection doesn't make any sense; only real solution is to come up with a full list of browsers that can't handle our HTML but that sucks because we'd need to test on a bagillion low-end devices
 * https://www.dropbox.com/s/840ftlrfygtou4m/browser-stats-mobile-20130610-20130616.zip
 * What does support vs not support mean? Do we test on all those browsers?
 * Don't support: We don't test, if we get bugs they are marked 'wontfix'
 * Support: Good faith effort to fix bugs
 * Would be nice to be able to drop a user-agent header into a form and see the % of usage
 * Maybe three levels of support: reader support, editor support, non-critical support
 * Kenan will work on getting list of browsers and % of traffic
 * Juliusz wants to make sure some engineers are involved in defining whether we support or not
 * Browsers can be grouped in different ways, see the above link for examples, e.g. sometimes Android 4 != Android 4 because 4.0 has a bug that 4.1 doesn't
 * But usage needs to be considered in a way sliced globally
 * a browser that has 1% worldwide traffic might have 30% traffic in developing targeted countries
 * Need communication with Zero team
 * Issues following standards, particularly with WAP/WML

Action!

 * Kenan will get better data; update browser support per quarter based on qualitative AND quantitiative metrics; decide how we'll provide testing coverage; if bugs come in for 'supported' browsers we make good-faith effort to fix otherwise wontfix
 * Do we support WAP now? Kenan will get numbers and we'll make a decision asap

Performance

 * HTMLFormatter-related stuff should be measured
 * Client side vs server-side performance
 * Client side - Juliusz wants metrics on the full client side experience; first byte received -> fully rendered and JS loaded
 * Kenan - 'time to first paint'
 * Do we currently have performance standards, particularly for desktop
 * Kenan wants to talk to PMs in other orgs to get a sense of their baselines/standards
 * NavigationTiming records DNS resolution, how long to transfer HTML, page load time, etc
 * Maybe use top 10 articles as baseline for rendering times
 * take into account where you are in the world, maybe even carrier
 * http://www.webpagetest.org/video/compare.php?tests=130715_82_3c03a9eb9339dcf8d3e82ed43ad2998d-l%3Aoriginal-r%3A3%2C130715_VZ_7748042f6f940ec663a43130cd597eee-l%3Amps-r%3A4%2C%2C%2C%2C&thumbSize=100&ival=100&end=visual
 * https://meta.wikimedia.org/wiki/Schema:NavigationTiming
 * Easy to get lost in sea of numbers around performance; can we use a particular page as a benchmark that we periodically check?
 * How good is our performance RIGHT NOW?
 * Let's get a benchmark of how our performance is right now, compare to sites with similar audience
 * Establish 3-5 metrics we can use for ongoing performance tracking
 * eg how long does it take for lead section to load
 * Measure data transfer (for initial page load)

Action

 * Kenan's going to talk to other PMs etc for benchmarking
 * Kenan's going to define spike(s) for finding our benchmarks
 * Juliusz will continue working with Ori around navtiming etc

QA/code coverage

 * figure out where we need to add aditional unit tests
 * determine code coverage for PHP/JS and ensure that it's being reviewed before we begin working on sepcific code areas
 * don't want to do arbitrary tests, rather informed tests that are meaningful
 * we'll be guineapigs/trail blazers for these tools
 * high expectations for unit tests around core code
 * Selenium tests?
 * We get notifications; there's a wiki page on what's covered
 * how are selenium tests defined? in response to bugs, previous breakage
 * have engineers start writing selenium tests? yes, but lower priority than getting a handle on unit tests

Action

 * Michelle to get us metrics around code coverage
 * Juliusz to give workshop around TDD (acceptance (selenium) tests, followed by unit tests, followed by code to make the tests pass)
 * Michelle to work with one of the engineers for finding the right JS-related tool for code coverage

Deplyoment train

 * blocked on testing on testwiki
 * betalabs nowhere near stable
 * mobile focussed produciton-like vagrant instance? (standard for eveyrone to test against, easy for new devs to get started, we control it rather than having no control over betalabs)
 * get mobile domain working for test2

Action

 * Michelle to coordinate with Chris about tests for test2
 * Need to get test2 to work with MF, then get on the train and see what happens (keep our window) [Arthur]

Code -> core

 * Currently have patchset around moving HTMLFormatter stuff to core, but blocked on comments
 * Max will prod this along
 * Other: HTML templates in JS (Hogan), wikitext-parsed messages in JS, some abstractions we use in JS (View?)
 * Clean up RL related code as part of code hygiene so it's ready to integration
 * Allow core migration convo to happen organically
 * Mobile detection in core? There's not a lot of detection logic anymore...
 * X-WAP header is still kinda wonky...
 * Should be done, but it is low priority
 * Use mediawiki.ui or stick with our own styles? Wait for Less support?
 * If we decide to use mediawiki.ui, make it thinner and not dependent on jQuery.UI
 * It's not dependent on jQuery.ui, but could always use some thinning

Action

 * Max to keep prodding HTMLFormatter patchsets
 * Focus on cleaning up RL related code to be ready for potential migration [Jon]

Involving community

 * Alpha/beta/stable scaring away potential contributors?
 * Gerrit scaring away new contributors?
 * Jon wants to attract new contributors (folks who've never contributed to MW code before)
 * Create a 'how to get started' page for MobileFrontend
 * Have a 'hello world' module
 * Add 'developers' link in footer?
 * Have a vagrant instance or instances (one for WM infrastructure, one for basic dev)

Action

 * Kaldari to own putting together documentation for getting started
 * Arthur to continue pushing WM prod vagrant instance for MF