Hello friends,
I'm working on a small side-projects called PRBoard (https://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!
Top comments (0)