-
Notifications
You must be signed in to change notification settings - Fork 2
Retrospective notes 2022.02.23
How to account to support work?
- Some tickets were created with appropriate amount of points in them
What would everyone's opinion be on trying to bring in one or two issues each sprint to automate some of the manual tests we do as part of preparing for releases to slowly begin chipping away at them to speed up release testing?
- Use Squish as we have it
- Always good to speed up release testing
- Difficult to prioritise testing higher than instrument work
- Occasionally convert one test after creating ticket and then review
- Have a list of tests/tasks/tickets on wiki for "spare moments" e.g. on Friday afternoon
- Decided to get ISIS cycle(s) out of the way first and then have another think, probably a meeting.
Would revisiting the concept of code freezes be a good idea?
- Not discussed in this retrospective
Can we consider using GitHub Discussions to contain technical conversations? I feel it may help us as a team to better organise and archive technical discussions taken place under custom categories and pin important conversations (sort of like an internal stack overflow). I believe it may also help reduce duplication of questions asked and answered within the team.
- Not discussed in this retrospective
Might be interesting to just discuss the idea of the ICD lightning talks we attended this week, seemed an interesting idea. Maybe we could put an odd slot in for one or two (e.g. one after stand-up once a week?). Not necessarily to to do a block meeting of them but let a few technical tricks and ideas out of the bag in a 1-2 minute slot. Could also be presented to ICD if appropriate.
- For info: 4 to 6 months is frequency for ICD talks
- Book weekly slot and people can volunteer if have something to talk about
- After Stand-Up meeting is ideal, if time allows and not running in to next meeting
- Give people option not to attend if not interested
- Suggestion is to have after Stand-Up of final day of sprint
What would everyone's opinion be regarding merging the Social and random teams channels together to reduce the number of channels we have? Is there history in one or both chats that we particularly care about and would prefer not to lose?
- Channels merged, topic closed
Can we discuss this ticket as a group to look at automating the release build?
- Not discussed in this retrospective
If we can be more descriptive / verbose with PR titles and descriptions, I like the idea of using the auto generated release notes feature on GitHub for release tags going forward. Currently PR's vary quite a lot in how well they are written so the auto generated release notes don't look very nice. If we can be stricter with how well we write PR's and commit messages (title and body), I would like to place the Release notes link in the release tag like we do already and then the auto generated release notes beneath that to be more descriptive with the changes included in each release tag per repository.
- Discussed as part of current retrospective, notes below
We probably don't need to buy a mic for the office webcam now, but it's probably worth shutting the door at standup as people walking past the office can be picked up on it now with the "low" noise suppression option ticked on zoom. Otherwise though I think it's much clearer!
DDaT launch PC recycling and sustainability scheme (sharepoint.com) Volunteers required to re-image obsolete (but still useful) IT equipment for resale to staff or donation to charity. Scheme currently being run from Polaris House, but maybe if/when expanded to RAL, could be an idea for a team-building exercise (or perhaps more of a bus man's holiday!)
How patched is the release? Was the timings good for us, did we get the change requirements before the cycle started?
- We still need some tidying to be done on sans2d
- Patching was made easier thanks to visual studio version being the same and because we had a developer build
- We had releases done by the time of testing on the instrument giving us extra time
- Overall we are happy with this. This workflow should be documented on wiki
If we can be more descriptive / verbose with PR titles and descriptions, I like the idea of using the auto generated release notes feature on GitHub for release tags going forward. Currently PR's vary quite a lot in how well they are written so the auto generated release notes don't look very nice. If we can be stricter with how well we write PR's and commit messages (title and body), I would like to place the Release notes link in the release tag like we do already and then the auto generated release notes beneath that to be more descriptive with the changes included in each release tag per repository.
- We looked at the draft of auto-generated release notes
- We decided that we should think about making pull request titles more descriptive but we will not be spending time on auto release notes
Would it help to know the points expected at the start of planning meetings to help with the awareness of what we can do?
- We will implement this and see how it goes for a couple of sprints
Do we want to rethink the way we approach discussion tickets? We often spend time discussing a discussion, then ask about MUST/SHOULD/COULD/WANT/NOT, then finally (hopefully) have the discussion. There are quite a few of these "decide on architecture" discussions in the backlog, and they can impede the code being done as we don't get around to the discussions. How about I (or someone else if they want to) books an architecture meeting for an hour or so every sprint or two (as with planning and review/retro they won't count for points). The agenda for the meeting will be based on recent proposals to begin with, and shared in advance. A backlog of discussion tickets can then be created and maintained offline (rather than in existing meetings).
- We should treat those tickets as a separate backlog for this purpose
- Meetings will be setup and we will try this for some time to see how it goes
Should we think about splitting planning during cycle too?
- We will be splitting during the cycle too so that team members that could be on support during one meeting can then join another meeting
We frequently run into problems with Eclipse RCP environments (IBEX client and Squish), would it be worth sending some people on some kind of training courses? I feel a bit guilty as I haven't found a lot of time recently to help people resolve these and I'm always just kind of muddling through myself, I think having some more expertise in the team would be useful. Anyone interested be learning more about this?
- We could send someone to a training on this and then that person would be able to help rest of the team with Eclipse related problems. We need to decide who should attend the training
I don't really understand the distinction between https://github.com/ISISComputingGroup/IBEX/wiki and the developers manual - should we merge the two?
- There is a reason to the separation. One is for developers only and the other for everyone
- We might have some content that's in wrong places that needs to be looked at
- We could use some version history but we are not urgent about this
Should we have a "team day" every month/other week where everyone comes in?
- Yes. There is a proposed date of 25th of March
- We discussed the issue of camera in the office