Previous Retrospective Actions

Action! Set up a meeting to discuss options for team split [DAN] DONE
Action! distill post-all hands awesomeness things that were helpful and add to app onboarding doc (https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Onboarding) [BRIAN] FAIL!!
Action! Schedule meeting to discuss new potential team norms and practices around our process, quality efforts, documentation, and other improvements (and how to measure success of these) [Tuesday March 3 proposed]) [KRISTEN] DONE but deferred; some (tech-centric) discussions have been happening regularly, although they're more code-centric
Action! (related to above) Brian share ideas about measuring our success and how can we make reflecting on our process more quantitative [BRIAN] DONE

Worked Well

Feature catchup iOS +1
Speedup refactors iOS
Gerrit was OK - but not great
Stronger shared understanding of user value
Better team collaboration iOS
I see phab is in worked poorly, but my workflow, at least, has been fairly painless. Less jumping between it and trello at least has been nice
iOS dev talks - documentation and code review +1
Spike for the Node service +1
Android beta releases continue to be painless and steady
It was painful, but crash reporting... we're so close! +1
- legal review is close!
Buggin' out (bug triage) +1
beta testing win: https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008705.html
Code Review
Build server is racked!

Sprint retrospective lag - I forget what happened - maybe do this meeting on Mondays? (ok sounds like since the last retro not neccesarily the last sprint?)
- should retros be sprint based?
Spikes in the same sprint as related user stories is suboptimal and leads to stress
- related to diminishing returns on readership? no :) (Dan)
<troll>Didn't ship an iOS AppStore release</troll> hahah-not trolling a real concern!
- release DAILY!!!!!!!!!!!!!
- don't release based on arbitrary intervals! keep master green! CONTINUOUS DELIVERRYYYYYY
Phabricator, and its many shades of grey
- open Phab ticket when you encounter problems
Android hiring still slow
Gerrit: hard to do lots of things..
- Follow convo threads
- Collaborate
- Follow iterative progress/amendments
Feedback on new changes: design & quality feedback loops are loooong (http://i2.kym-cdn.com/photos/images/original/000/356/149/c07.gif
Code review is a bit slow (see "gerrit is hard" comment)

Uncertain future for team structure + (db)
How do we want to deal with i18n on iOS?
- there are open questions, Android side seems clearer?
Exact approach for Hackathon

Testing (+1 BG)

Why can't we allow pull request on Github? ++++
- Action! Yuvi set up a magical bridge - talk to him! oh crap bernd already talked to him.
- Gabriel and RESTBase team may have a clever mirroring solution...
- Chad Horohoe may advise

Do some sleuthing around the org (see peeps who were called out above) to see what has been done and what might be feasible [COREY]

Large amount of untested code - big risk +++
Design workflow with devs - uncodified (<-Corey :-)) +1+1 ++
- need more lead time
- implicitly falls into "Ready for signoff" along w/ other things
Release Process, QA - no real process + +
What our release plan is: can we get more transparency or frequent updates about code & feature freeze, e.g. how many days until either and how on target we are? +1 + (see release process, QA, above)
Big gaps between Android production releases. Lots of repeated bug reports in OTRS of bugs that are already fixed in beta but have not been rolled out to production. +1+1 + +
- can we get closer to continuous delivery