Not sure if anyone else has some good ways of working with PRs, but we've had some minor (but constant...) pain points working with PRs in the new UI. They're pretty much echoing a lot of the feedback that was originally given by the community (see the original community post) but the main issue is the split of "what needs reviewing".
Long story short, the review process we have around PRs focuses on a few main parts:
- Actual code review - ie: the Files Changed PR tab
- Some external reviews of build results (notably Chromatic for UI change review, plus build/test failures, etc) - ie: the "builds passed" list
The process for the PR Creator here is more or less fine - they can open up on the Overview tab and see the Reviewer's approval state, plus build states etc. We've also got things set up to correctly block merges if there are failed builds / lack of approval, etc.
The issue we have is around the Reviewer's experience. The difficulty is the split onto two separate views of the information they care about, and that there's nothing stopping a reviewer from approving a PR that has pending/failed builds, unresolved tasks, etc... The reviewer naturally tends to spend most of their time on the Files Changed tab - so a failed build is hidden from their view.
The result is that a substantial portion of our PRs get fired back to the Creator with an approval but failed builds or incomplete tasks/builds, so it needs to be fired back to the Reviewer again... Just ends up wasting time and causing extra friction within the team that we could definitely do without.
Any ideas of good ways to deal with this? Any ways of blocking approval based on rules, etc? Even just ways of adjusting our processes so that Reviewers can't miss their required tasks would be great :)
Thanks in advance!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.