-
Notifications
You must be signed in to change notification settings - Fork 2
Retrospective notes 2021.05.05
mihai-stfc edited this page May 7, 2021
·
1 revision
- Managing security issues - current org. concern because of many different types of security vulnerabilities
- Ticket, PR & Branch clean-up - do a proper cleanup over the shutdown, and as we notice them
- Short-staffed when urgent workload is high - point for 4 weeks of work and do Fridays if not doing support
- Themed sprints
Future Ideas wiki page
- Used for long-term planning, "idea repository". Should we maintain this?
- people haven't added anything in there recently
- unsure of how to keep track of things in the long term
- good place for things that are nice to do and would like to when we have the time
- great place for tasks for placement/graduates
- Keep it
- traditionally the selected cards are not anonymous
- would we prefer anonymous, or displaying the vote cast?
- No strong opinions, keep it as is
- hasn't bothered anyone
- good to see what goes in and out
- this round has been relatively calm, but it has still had its moments
- there have been discussions in the past, but is it worth thinking about it and revisiting it towards the end of this calendar year?
- do deployments much earlier, 2 weeks is too late; can deploy early is release is ready
- release was getting pushed back because of MUSR, stop doing that - release for all instruments and do a MUSR patch release late
- make sure to tell the scientists that we are deploying to establish hard deadline; scientists also want a window, so they know when to be available
- don't delay the release unless it breaks instruments - if not ready before the start of release sprint, don't add it
- need time to decompress after this sprint
- pushing ourselves hard to get things ready for cycle - this is affecting morale
- we should think about ways to avoid this happening again
- it has been a bit stressful but overall people feel ok
- if it helps, can "dial-down" next sprint
- we should send more technical articles round the group, should we have a channel?
- don't want people to feel obligated to read it
- reading could be allocated as training time
- see if people are okay with 2 chapters in a month, if not maybe 1 chapter
- neutron training course was the same (though it was more on the physics side of things), while this could be more about software
- this channel could be good training. Try to pick a book or online articles and discuss it at a code chat, see how it goes
- How are we counting support tasks? 0 pointers or not?
- allowed to be 0, but if it takes time it shouldn't be
- burndown chart is -20 because of the support chunk
- decide capacity according to trend and keep to it
- carry on with support being 0 as long as it doesn't take too much time
- is second week in cycle still too early for a sprint review? still busy on support.
- always going to be hard and there's always the possibility of support calls in the middle of it
- maybe split the meetings to be "less interrupted" if something comes up, instead of having a long meeting
- yes, split reviews and retrospectives.
- Change meeting time to an hour