Retrospective notes 21/07/2021

Items from last retro

• Tech-debt and Fridays have been collaborative which is good! Similar comments about planning tickets for Friday. Plan is to make a ticket to organise Fridays/tech-debt so meetings are had to plan and review tickets. We should have 2 standups to encourage collaboration or a channel that is always open to drop in and out of.
• Improved automation of the board is nice.
• Kathryn has deleted a couple of unused project boards which is good.
• Code chats should be organised to talk about investigating new technologies.
• Important dates: we need to check if alerts work, adding important dates have been useful
• Having new starters on site means that we organise ourselves more to get on site which is good. We should look at continuing this.

Coffee

• Let's make coffee a very short second stand-up and then people can stay on for coffee
• It's ok to send apologies if you're busy just like in the mornings
• Need agreement from Freddie
• Compulsory to either attend or message why you are not attending

Passivity

• We don't tell people we need to do something until we are doing it, we should give more warning for things like getting requirements, doing deployments etc.
• How can we become more proactive?
• Who owns the NDX, how can we share it better with the instrument scientists? This needs to be discussed more in depth
• An example is the SANS2D migration where scientists didn't know about the component steward and talked to different people for each ticket

Keeper

• Someone needs to try out keeper to discuss how it works and present if we can use it and how to migrate to it (maybe at a code chat)
• Jack will do it, James will organise the code chat

Issue templates

• We can have multiple templates to choose between (this is useful for releases and a generic release template)
• Our current generic template contains a standard title "Component: Short description", a user story with some more detail, acceptance criteria and some extra notes
• We can change the generic template but we need to make sure our process is light and tickets are readable
• Though including things like where is the code
• We use issues as user stories not issues in reality
• Jack has previously used
  1. How: What is the issue
  2. Where: Where the issue is likely to be (being as specific as possible inducing relative file paths etc)
  3. How: How did the issue come about
  4. Reproducible: Yes/No and any additional information
  5. How to test the issue is resolved: A set of instructions / a script / include test file if required to act as a reference for the developer when tackling the issue and the reviewer when work is complete.
• Both Jacks will write their own and compete to win the ultimate issue template

Burndown suggesting we haven't done enough

• Yes it was difficult to calculate this at the start with so many unknowns

Tasks board isn't being interacted with much

• We will put some into proposals that we can do as actual tickets
• It's not so useful out of sprint
• We should tidy it up soon