-
Notifications
You must be signed in to change notification settings - Fork 2
Retrospective notes 2021.12.15
| Chair | Timekeeper | Note Taker |
|---|---|---|
| @JackEAllen | @daryakoskeroglu | @Adam-Szw |
We didn't get to test it yet. We should try this at the next opportunity.
We made some effort to increase amount of reviews coming through, especially among junior team members. As we are making effort towards adding more of 'how to review' instructions to our tickets, we need to keep in mind not to post any security risks that come with having our project be a public repository. These could for example include IP addresses, device names etc.
Mutual agreement that during the final week of a sprint, the squish license should be used primarily for reviews only. The priority of squish license usage during the final week of a sprint can be prioritised as:
- High: Reviews
- Medium: Reworks
- Low: New work
We tried to follow this ruleset during this sprint and it seems to have worked. We agreed to keep this in place.
This issue hasn't been dealt with yet.
We did the secret santa and the team enjoyed it. We are yet to organize a new year's meal.
These are generally not as readily visible as the projects etc. are in GitHub
Apart from trying to be organised next time and realise in better time when it isn't worth having a pre-planning meeting, are we happy with not having one when it feels unhelpful?
Considering how this is a rare situation, we agreed that the best way to deal with it will be asking this question at the end of the standup, so that people can have an opportunity to voice their opinions on this.
This keeps getting brought up, but I think we should have a 'cull' of icp-write members for the sake of security in case anyone's GH account is compromised and they are difficult to reach
For the security reasons we agreed to:
- Everyone should make sure that they are using 2-factor authentication on Github
- We might want to look into removing members who have not been on the project for a long time
We decided to go for it as nobody had an issue with that
Some new members of the team have trouble merging branches on various repositories due to lack of permissions
What is the best way not to forget to update submodules - should EPICS_repo_checks post a message to Teams on failure?
- We decided not to add message on teams.
- We might consider adding checks or 'todos' in the templates to remind people.
- Optionally we could add a pre-commit message check.
When adding new sections or editing existing sections of the wiki, I would like descriptions to be as verbose as possible to be more accommodating to new members within the team
We can make things more verbose where we can, but we have to look out for possibility of duplicating information. Where it exists, we should favour linking other pages rather than keeping extensive amounts of information on one page.