2021-07-21

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.

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

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

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

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