Reading/Multimedia/Retrospectives/2019-03-28

From mediawiki.org

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

------------------------------------------------------------