-
Notifications
You must be signed in to change notification settings - Fork 2
Retrospective Notes 2020.08.19
ChrisColeExpControl edited this page Sep 17, 2020
·
5 revisions
- We are fine with the size labels on PRs
- We are fine with the way impeded issues are handled
- arrival at meetings- got better immediately after but diminished again, we will start on time anyway
- Might try to virtually "get up" in teams to prompt others to join standup
- coffee attendance is slightly better but still less than ideal.
- we were implementing more tickets than reviewing, this seems to have changed now
- this being brought up has driven people to review more
- we've got more points done than predicted, maybe because of not doing as well last sprint.
- try not to read too much into the burn down graph
- meeting roles seem to be working
- did we make this release more stressful by imposing arbitrary deadlines? Possibly, but it's more likely that they will always be stressful
- maybe don't leave enough time between manual system tests and first deployment
- need to have a meeting about manual which system tests need to be removed
- can only store them for 3 months anyway, and need to have permission of all involved, so might be not worth the effort
- especially if something changes in the future making the code chat outdated, a new watcher might become misinformed
- only record if somebody is unable to attend but wants to see it
- only record if everyone is comfortable being recorded, if you are uncomfortable being recorded but not willing to speak up about it, contact K.B. or D.O. and they will champion the issue.
- this is equivalent of our tech debt stand down, but for a week.
- Mantid has more of a need for this than we do due to the size of their team and the manner in which they manage their development
- We might put aside a "no new dev work" sprint in long shutdown, and maybe 1 week per year of this, but no changes right now.
- No, this is the purpose of the build servers, only run them on your machine if you think it will break a system test
- Could try to put something on Jenkins to highlight what was added since the last success, but this might not be possible/helpful given the large number of repositories they are reliant on
- Perhaps add a step in the PR template to check if anything might impact a system tests, but might be hard to follow due to breadth of system tests
- Change it to one page with headers for the each release instead of one per demo meeting.
- Move all previous pages into same format.
- If only one person is attending molecular spectroscopy demos each month maybe add them to another group to save dev time
- Potentially present to their group meeting, check with them.
- we've got more points done than predicted, maybe because of not doing as well last sprint.
- try not to read too much into the burn down graph
- will see if it continues to next sprint
- If people want to change it then they can do so at their leisure, list is useful so people don't get surprised by being at the start, also highlights people who aren't there.