Reading/Multimedia/Retrospectives/2019-03-28

2019-03-28

Previous Action Items


 * Max B to send out explicit template instructions for Multimedia specific tasks


 * Matthias to dig up some UploadWizard tickets and see if they are worth prioritizing (Ramsey)

What are we doing that we should keep doing?


 * Keep Smiling, keep shining+1


 * Acceptance criteria/QA steps for QA thanks matthias for really handling that on multiple tickets


 * Writing unit tests!


 * Talking to each other...a lot +!+1

What are we doing that we should stop doing?


 * Using 3 different video chat services?


 * Adding new work before finishing old? +🚀🛸🎅


 * Writing large patches that touch lots of code and constantly have merge conflicts, even if sometimes this is the only way to accomplish a task. I am the one primarily guilty of this, apologies.


 * Talking about things on mutiple chat services (like the blocking CI) 🛸:P☝️


 * IDK where to put this, but we have a complex thing going on, with search, qualifiers & UW "done" (merged), but disabled - how to best handle this?☝️

What aren't we doing that we should we start doing?


 * I know this is impossible but ... regression testing :/ We can write unit tests now at least! 🛸🚀


 * \o/


 * Given the incident yesterday we may get a little more help here.


 * Usually for regression testing we should have 'happy paths' defined. What are our most used/sensitive code paths (user actions) that we want to safeguard from regression


 * We had a high-level product discussion earlier this week about how to move from depicts -> generic statement handling. I think a lot of things about that were unclear for me until we could have a dev + product chat. Would be good to find time for more discussions like this, but it's difficult because of time zones. :P☝️


 * Let Max know/file a ticket via template when a new board/tag/milestone is created so he can update Herald


 * This sprint we had multiple tickets (all design/css related, often with trickle effects on each other) being addressed in a single patch.  There was some confusion around this.  In general, there is not always going to be a 1:1 correspondence between tickets and code patches - how should we address in the future🎅🚀


 * IMO, this is usually fine - if another (unmreged) patch helps your new thing, use it... (maybe separate patches that depend on one another, but whatever works and makes most sense at that time)


 * Talk about where to track blockers that other teams must resolve🎅

Topics voted up (as needed)


 * Adding new work before finishing old? +🚀🛸🎅


 * What is the def of done? Verify on prod is done for devs


 * Only reviewing API changes for devs looking at this


 * Who verifies on prod? Ramsey? QA? Not much to do with code that is on prod. Emergency revert only.


 * When things are in QA, we tend to ignore


 * What if we closed tickets by a certain point, such as the end of the sprint?


 * What if we verify somewhere besides prod?


 * We need a true mirror


 * Test commons is close, but not quite, so prod is what we got


 * Talking about things on mutiple chat services (like the blocking CI) 🛸:P☝️

Parking Lot







Action Items


 * Matthias to dig up some UploadWizard tickets and see if they are worth prioritizing (Ramsey)


 * Max to email list to see what we can do about


 * getting a sense of accomplishment (via resolution of tasks probably)


 * Figuring out how to verify tasks on prod without clogging board)


 * Use multimedia-team@lists.wikimedia.org for discussion of ad-hoc ticket needs/emergencies