1) Speeding up code review (and delivery)
Pinging the dev channel increase transparency and engagement
Downside is: it can get noisy. Using discretion is a good idea, and including few words/lines on what the PR is about adding a few lines on the scope
bring back the priority tag;
pair programming - we haven’t really tried that - making use of the time shift difference. Suggested that this might be particularly useful in the big issues.
Tax reports work - having multiple people working on a task can make the scope explode
Let’s keep iterating, as not all issues are appropriate to share, there’s a skill matching needed as well.
Conclusions and summary
A great discussion, no definitive conclusion.
- try to obtain feedback earlier in the work (before code review)
- GH notifications may be missed - feel free to ping directly on Slack
- do more one-to-one meetings
- planning ahead when starting off a feature
2) UK downtime
Strong hunch - memory issues due to reports; proposal: we need a volunteer to check if we have puma restarts are on; we need to verify if its the case, if not it needs to be re-enabled. We need to open an issue for the UK downtimes.
- proceed with background reports → green light to remove the toggle and enable it in prod
Thoughts on rolling-out:
- download reports are under the same feature toggle
- improve UX: message is hardly visible; it can be misleading for users. It’s an easy fix to improve the UI (increase font size)
A dev needs to have a look on how to create a production server for n8n - @dcook to join upcoming call
4) Broken build due to merging old branch
How to prevent this?
- Re-triggering the build (manually, under the Actions tab) should consider the current master (this needs to be verified @filipefurtado @dcook )
- If so, then re-triggering the build is preferred over rebasing by hitting the Rebase button on the Github-UI (which also triggers the build but re-writes the commit history)
- Quick round: gathering feedback on issues where people are blocked
- Dev Ready column sorted