We use Jira, GitLab and Slack in our agile teams at work. I've written some automation that listens to GitLab webhooks and (a) announces new Merge Requests in t

We use Jira, GitLab and Slack in our agile teams at work. I've written some automation that listens to GitLab webhooks and (a) announces new Merge Requests in the #team-review channel, which all team members are in, and (b) creates sub-tasks on the original Jira story or bug, which appears on our Jira boards. But yeah, most of it is about setting expectations. I think our conclusion was mostly that review times under about ~24h are okay, so within that space people can organize their own time. That said, I have been trying to get my team members to create smaller commits. I'm personally convinced that review time is exponential in commit size, such that reviewing a branch with 20 small commits is much more efficient than one squashed commit. That said, this hinges on actually doing the work to create good commits: no fixup commits, one logical change per commit, etc. This has come up enough that I think I should write a blog post about it some time.