My FeedDiscussionsHeadless CMS
New
Sign in
Log inSign up
Learn more about Hashnode Headless CMSHashnode Headless CMS
Collaborate seamlessly with Hashnode Headless CMS for Enterprise.
Upgrade ✨Learn more

How do you work with pull requests at work?

Ivan Bokii's photo
Ivan Bokii
·May 24, 2020

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:

  1. 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.

  2. 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.

  3. 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!