Wikimedia Apps/Team/Retrospectives/Retrospective-iOS-Github-2015-08-03

=iOS Github Retrospective=
 * Invited: Adam Baso, Brian Gerstle, Bryan Davis, Dan Duvall, Greg Grossmeier, Corey Floyd, Monte Hurd
 * Attended: Adam, Brian, Bryan, Greg, Corey
 * (Through a miscommunication/oversight, Max Binder didn't get invited)
 * Facilitator: Kevin Smith

=History:=
 * Corey/Brian joined in Dec 2014/Jan 2015. "How do you guys do build and testing?" Answer was manually.
 * Got checklist going. Goal was to automate.
 * Can not build at all on Linux box; need to be built on OSX.
 * First step was to have a Mac mini running Jenkins; downloaded source and pushed build somewhere
 * Wanted to run tests on the box. Travis and Github entered the conversation.
 * Brian Gerstle: ^ to be clear, we could run tests on the box, but we were getting 0 feedback where we really needed it: in the code review system (Gerrit)
 * Lots of discussions happened during the May 2015 hackathon in Lyon
 * Discussed costs.
 * Brian Gerstle: ^ we roughly discussed implementation details, enough to establish that DIY would have been a non-trivial, long-term undertaking which neither iOS nor RelEng/QA were interested in shouldering in the near term.
 * Antoine Musso: caused a few operating challenges such as how to maintain yet another OS (Mac) and how well Xcode could be driven from CI/Jenkins. We discussed used of alternative third parties.

=Discussion=
 * Greg: Nobody wants to maintain Mac minis. neither Operations or RelEng can devote time to support Mac minis,
 * especially for an app that has relatively few page views. Was not going to make the cut in the next year.
 * "Isn't there a way for Travis to work with Gerrit?"
 * Brian isn't aware of a Travis/Gerrit option. Would have been open to it, but would have been a lot more work.
 * Could shift to that, but would need training to get iOS team up to speed with gerritt
 * C Scott sent a proof of concept to the QA mailing list of doing that, so that might be an option.
 * Greg: No communications iOS-RelEng in last month or so.
 * Jumped from "considering" to "decided" with no public conversation. Greg: "Just not how things are done here"


 * There was silence after the hackathon. Brian tried indirectly to get the conversation going again.
 * Team still feeling the pain of not having integration.
 * This meeting is the first time Brian is hearing that RelEng won't support iOS. Would have helped to have heard that earlier.
 * Best option seemed to be Travis (which is free) which we already know.
 * Saw NPM option (from C Scott), but not reasonable to expect the iOS team to put in that level of effort.
 * One good outcome: Have a plan to handle this kind of conversation.


 * Greg had really hoped to be able to support iOS, but reality has set in. Agree would have been nice to know/say earlier.
 * Apologized for not expressing earlier that they couldn't, since he really would like to.


 * Action item after Lyon was: How to integrate OSX machine into the build chain. VPS is closed source.
 * Could buy and maintain our own machines, but high staff costs. Outsource to Travis w/virtual OS machines.
 * Travis only supports github; others support systems like bitbucket, but still the same problem (not gerritt).
 * After a couple weeks of distractions, Brian contacted people directly, but didn't get responses.
 * Turned to Adam, and just tried to move forward.
 * Responses to earlier email (e.g. "your team shouldn't exist") were a deterrant to sending a wider email, and
 * contributed to only reaching out to individuals at this point.


 * Reminds G of MP4 discussion. That was a stereotypical discussion for that kind of proposal (proprietary vs. free).
 * Robla gave great advice: There will always be those who communicate badly and sound like trolls. They (sometimes) also say useful things. So ignore the 90% useless and focus on the nuggets of usefullness even though it's hard to do.


 * Conscious decision to send "notification" email rather than "RfC".
 * Intent was: "We're going to do it unless someone gives us a better idea"


 * Greg requested a public conversation before he left. Why didn't that happen?
 * (If there was a clear answer, I didn't capture it in my notes)
 * ^ BG: My perspective on this is: after my initial attempts to restart the conversation w/ Greg (who then looped in others), I got no response, so asked Adam for support. From that point on all communications from Greg were "arbitrated" by Adam.
 * Adam: Tone of email could have been different. Should have emailed Greg with the message to get feedback.
 * If we can't come to agreement on something like this, it should get escalated as necessary.
 * (when pragmatic option is at odds with values of the org)


 * Corey: This wasn't a sudden thing. Had dragged on for months. This was the culmination.
 * At some point, you have to get pragmatic. The input had trailed off, with breakdowns in communication all over the place.
 * Original ticket was declined abruptly.


 * Bryan: Be more responsive when people reach out for help. Look for alternatives rather than just saying "no"


 * Brian: Maybe look at another case that went differently: crash reporting.
 * The main difference is that someone (Yuvi) experimented in labs, which led them to a more open provider
 * Another example is where someone pointed out an open code coverage option.
 * Good part of the new staff guidelines, "commitments instead of complaints"
 * Commit to trying to keep the conversation open, but find a way to get to a compromise.


 * Github is a lightning rod, for a variety of reasons.
 * Greg: We are frustrated because we want away from Gerritt, but hard to do so

=Takeaways:=
 * Flag issues like this. Be aware of lightning rods. Be realistic about resource options and be willing to say "no" when necessary.
 * Public/open/wider discussions can raise new possible solutions, but also help people feel included and informed
 * Next time we're together: group hug

=Retro of this meeting:=
 * Good that we started with the basic premise
 * I feel like I got my story out
 * Walking away feeling good.
 * We talked about resolution points, so it would be good to see where those go
 * When Greg first got the pre-retro invite, thought: "Why talk about it before the discussion?"
 * But the pre-talk was useful for both Kevin and Greg (helped to voice ideas once before the real meeting)
 * ^ BG: I would've also liked a pre-talk, or at least clearer expectations (if possible) on what's going to come out of the meeting.
 * It's good to actually talk about areas of friction like this, rather than relying entirely on email/phab/IRC