What I’m calling a “never-ending PR” here is a PR that is attracting lots of discussion and comments from different people. Once one comment gets resolved another one opens up. Eventually it gets to a point where we just want to do whatever we can to resolve all comments and merge the PR, even if we don’t agree with what has been suggested.
PRs should have limited but concrete scope. That is the task should be well understood and be manageable in size. Well understood means the general solution is known to all team members before someone starts working on it. This is not always easy, especially if the PR involves multiple teams or unknown systems. Concrete scope means the resulting PR won’t be huge. Having enormous PRs is another bad sign as they are rarely easy to review to an acceptable degree.
So what should we do about never-ending PRs. There’s two general types of discussions that happen on these PRs which lead to different solutions. The first are ones that surround technical details and the second focus on conceptual ideas.
Technical feedback is where the reviewer is focusing on the mechanics of the code. Maybe a function named incorrectly or something that could be refactored out somewhere else. Usually it is because they have a different understanding of the code. I think the best way to solve this sort of technical feedback is for the reviewer to pair with the person who opened the PR to get their ideas across instead of scattering them across comments on the PR.
The second type are conceptual discussions. These are ones where the reviewer had in their mind a completely different idea of how the task should be done. These ones are difficult to get across in review comments and again are best solved by both meeting and scoping out the better solution. Maybe here the task needs to be more well refined so instead of jumping into the code focus on ensuring everyone is on the same page with how the task could be solved. This could be brainstorming out different ways of solving the task and most importantly deciding a way to proceed.
However this is a sign that perhaps the task itself should have been scoped out better when it was being created. If two people have two completely different ideas on how to solve a task the discussion should be had much earlier than when the PR has been created. If something was found while doing the task that made the resulting solution different to what was agreed earlier then it should be communicated to the team while in the middle of the task.
Never-ending PRs are usually a sign something has broken somewhere else so solving the symptom won’t yield much benefit if the cause isn’t looked at. Likely the cause is poor communication somewhere in the line. Communication is vital for effective teams to plan and coordinate together so a number of these should be a sign for the team to take a look at how to improve their process. Better refining of tasks would help avoid these types of PRs but sometimes this isn’t possible so in this case the rest of the team should be kept up to date with the encountered issues.