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!
Normally a PR is considered “ready for review” if a review was requested, and you can set a policy that a PR cannot be merged without an approving review. Anyone can leave review comments though, even if a review wasn’t requested. You might need a role user whose only job is to be the requested reviewer and make the final approve/deny review.
GH also supports a “draft” state for PRs, so you could just treat everything not in draft to be ready for review. Before there were drafts, my team just used labels.
Oh and your item #1 is just one reason why I don’t bother with monorepos. Interesting idea, but a disaster with git IMHO. I do like the PRBoard idea for multiple repos though – one pain point is that my boss will forget my PRs are up because he’s too busy flipping between multiple projects.
1 Like
Hi Chuck, thank you for the reply, it’s really helpful!. Do you need to remind that designated reviewer about some urgent PRs from time to time? Does your team work and own only a single PR not multiple ones and it’s only your boss who needs to switching between multiple projects?
Also, what’s the most annoying part of the PR review process for you and your team?
Regards!
Are you targeting big companies or small companies?
I’ve managed a few teams over the last few years and intra-team PRs have never been an issue, occasionally a PR sits a day or two too long, but the developer who wrote the code is responsible for getting it deployed overall. They will nudge their teammates if it’s urgent and it’s not getting attention.
On teams where communication is good, it’s not really a problem.
The bigger problem has been with inter-team PRs. Perhaps we need a change in a completely different team’s codebase. We submit a PR, but it’s not high priority for them, so it sits for a while.
However, I don’t think this is a pull-request tool issue, but a prioritization issue.
Lastly, we had many repositories we worked across. In order to have a single place to view open PRs, I wrote a simple chrome extension which checked our github periodically. It also was configurable to send you a notice if a PR had stayed open longer than X days.
We’re a small team to start with, and the project I’m on is effectively a two-person project, with one other getting ramped up. Me and my boss are on that project, so we review each others PRs and push them on approval.
For the most part, I personally work on one PR at a time, but I will have several open and revise them as I get review feedback. And yes, I have to remind my boss all the time, since he’s always putting out fires for bigger customers, while I’m mostly focused on just a single project with a couple on the back burner to jump on when needed. That’s the way I prefer it, since he knows I’m pretty slow to switch gears.
The most annoying part of the review process is the primitive UI that github offers for it. I used to use SmartBear Collaborator and while it wasn’t awesome, it was far better than github’s review UI.