Readers/Web/Team/Retrospectives/Retrobreakfast

Overview

Where, Who, When

• The Grove, SF
• B Mansurov, M Semenik, K Lans (facilitating), J Hernandez, J Robson, J Katz (taking notes), R Kaldari, M Pinchuk, M Syed, K Hammerstein, R Moen, S Smith
• January 23, 2015

Purpose & Background

Dedicated time to close the loop on our learnings about transitioning from megateam to our current state and discuss options for working with the developer backlog going forward. Discussion of lessons learned, areas to improve, and directions forward.

Developer backlog experiment: https://docs.google.com/a/wikimedia.org/document/d/1NqzIX9hXJbaY-ke6uWThKFBEj7CUweSQrw6cCR_fGcY/edit

Blog post about experiment: https://blog.wikimedia.org/2014/12/10/an-experiment-in-self-organization-at-the-wikimedia-foundation/

Developer backlog: https://trello.com/b/DWuSeWBE/mobile-web-developers-backlog

What did we like

• Ryan: I stopped going crazy. Planning, analysis, and triaging got way easier. Glad Jon could step up and rally team and help.
• Moiz: (talking about second split) Whole thing was weird at first and has been a pleasant surprise to see both projects making progress. Shoutout to Jon and Ryan for leading teams.
• Maryana: impressed we recognized problem (tech surplus) and found a great solution quickly (new team). All done in less than a month. Very proud
• Jon: Really good to get devs together to talk about code base.
• Kristen: Cool that we are able to pivot so quickly...what seems slow to us is fast for everyone else.
• Rob: Change felt very abrupt, but that was necessary to keep rest of team functioning.

Kristen reorients conversation around dev backlog (not team split)

• Baha: Dev backlog was great. Always something for him to do. If he ever was waiting for something, find some task and experiment on it. (+1 Rob) This is also good for developing code health to make further change easier.
• Sam: Sam is very happy that they were able to choose topic, and that this topic was codebase health. Never worked for an org that honored the desire to take time to work on code quality. Very important that the dev backlog is public and PM’s and Kristen can all see it. Visibility important for pushing back on new features if code needs work.
• Max: Main result is that we have tried it and learned. If we go a little bit further and have specific resource allocation needs, then we will be better at it.
• Jon: Great to be able to find time to contribute to the open source community. Great to give back.
• Joaquin: We should continue to pay attention to developer backlog and talk about it. ACTION
• Rob: Wehenver we see notes in code like “fix me” we should add to backlog.
• Moiz: Kristen is the best. Thank you to Kristen!
• Ryan: Didn’t alienate single volunteer devleoper, who is still actively editing
• Maryana: Great that this was bottom up!

What didn’t work

• Max: number of regressions didn’t decrease; all over bugs went up (things were broken in refactoring)
• Sam: As a remote person, didn’t see any of these regressions. Would like more visibility. Deployments done while he is asleep.
• Jon: Despite more regressions, feels like the code is still healthier and we have better tests. This was hopefully a 1-time hit).
• Trello didn’t work well cause it alienated community. we should move to phabricator
• Ryan: Because of so much refactoring it really did make deployments harder (dependencies and merge conflicts)
• Moiz: no clarity on why wikigrok is not in production yet? We should be calling out any barriers/roadblocks on mailiing lists/forums
• Max: answer--wikidata is crap]
• ...What specifically, lets unpack that.
• Joaquin: Wikigrok is badly written: design and test coverage. I think we can do better. Probably need for speed caused this.
• [Answer: it is a prototype, so we will toss it and rebuild, once we have user data, we will know which version to go forward with and build right, and add i18n--see action below].

What is confusing us

• Why aren’t we doing weekly deployments
• Jon: It wasn’t clear in the dev backlog what was a feature and what was legitimately about code base health, and what is in scope for mobile (example: desktop categories apgae); we should be clear about how we handle that moving forward
• Rob: How are we going to move forward with collections re: backend and how much it overlaps with collections extension.
• Moiz: Some folks seem confused about team transitions and how that works as folks move from one team to another. (Moiz included in that). Example: collections will need backend help.
• Baha: Do designers use phabricator? There are bugs that need work.
• Ryan: what is better for pinging designers? [answer: Trello, hard to find and bad notifications in phabricator]
• Kaity confused by phabricator

Action Items

• Meet with Amir to talk through i18n
• Migrate dev backlog from trello to phab
• We should continue to pay attention to developer backlog and talk about it. Jon: maybe 1x a month to groom dev backlog. Invite PMs. Make it mobile-wide. Adding to backlog can be done asynch.
• Figure out criteria for what legitimately belongs in dev backlog and how we prioritize
• Setup a session to talk about how we use phabricator, in conjunction with Gerrit and other tech talk (due to developer trello preference and fact that some things only in phabricator
• Kaity should get some help on phabricator but also make sure problems are made known to folks working on it