Hello friends,
I'm working on a small side-projects called PRBoard (prboard.dev). It's a dashboard for teams that host their repos on GitHub. I'm currently in the market-validation phase, and I think some of my assumptions on how this product can be helpful for teams are invalid. For this reason, I'm gathering different ways engineering teams work with pull requests.
For example, in my team, when someone creates a new pull request, they send a message on Slack about it. We rarely use GitHub's built-in "assignees" and "reviewers" features because usually, it's more than one person who can review a pull request. When someone picks a PR, they usually leave an emoji on the original slack message signalling that they're starting the review.
There's a couple of downsides to the described approach:
No clear picture of all currently open PRs from my team. We structure code as one big monorepo with multiple teams working on separate code paths. This makes using GitHub's pull requests page almost impossible.
No way to know when a pull request is ready to be reviewed. We have a CI pipeline running different checks for every PR. It makes little sense to review a pull request that hasn't passed all test yet since there might be failures and further changes to address them.
There's no way for PR author to know when their pull request is ready to be merged
How does this process work in your team and are you happy with it? What's the most annoying part of reviewing others pull requests?
Regards!
I’m not sure I understand your issue, so please forgive me if my answer isn't as helpful as I wish
I think all the tooling like Slack or Teams could help with the flow, but will not solve if the basics are not in place. So let’s review the basic problems (as I understood them)
The part which confuses me is:
No way to know when a pull request is ready to be reviewed.
It seems to be a bottleneck.
Both in my current and previous team, we had a simple rule: if a PR is opened, that means it’s ready for review and test must pass. If you’re still working on it, add a WIP: prefix in the PR title.
It really makes it easy to see what’s ready to review or not. Code review is a shared responsibility between the submitter and the reviewers. The submitter needs to make sure the PR provides good review context, which implies the basic «is it ready for review» info, but also all the context required to help the reviewer focus on the most relevant parts. And the reviewers have the responsibility to give quick (for some definition of quick), constructive feedback.
There's no way for PR author to know when their pull request is ready to be merged Same thing: a simple rule like 1 approval, or 2 approvals should be enough here. (Actually I haven’t used Github in a little while, but that’s something we enforce on Gitlab)
We rarely use GitHub's built-in "assignees" and "reviewers" features because usually, it's more than one person who can review a pull request. (...) No clear picture of all currently open PRs from my team. We structure code as one big monorepo with multiple teams working on separate code paths. This makes using GitHub's pull requests page almost impossible.
Maybe I missed the obvious, but wouldn’t using the reviewers feature solve the issue? It’s build for that ;) If there’s only one or two reviewers who would be relevant for a PR review, then it’s very easy for the submitter to set them (and usually, as a fallback, tools like git blame give a good idea of the good potential reviewers who already worked on the codebase which has been modified) If people know that they should focus their review on the PR on which they are assigned, it makes the review process much easier. It’s very little effort for the PR submitter, and makes it so much easier for the reviewers. And suddenly Gtihub’s github.com/pulls/review-requested becomes very useful ;)
Hi Ivan, I follow same approach but in different way. I am using MS Teams for PR review. These are the steps:
We use Microsoft team with a bot that alerts in a channel when a PR is open, it was the same with slack. When opening the PR you assign as many people you want to have the PR reviewed and if you mistakenly omit someone they can still review it. The CI pipeline will flag if there is a failing test or something else. Everyone who has approved the PR has the green icon next to their name on Github.
Sky Jackson
Hey, new here and I read your blog its very good.