I'm searching for resources about code review processes. Feel free to reply with your experiences too. I'm not interested in technical matters right now like how to automate parts of code review or your Opinion about the right size of a pull request. I'm asking about the social process of deciding when to merge. How do you ensure quality and keep development moving ahead without getting dragged down by disagreements? Boosts appreciated.
Insist on keeping things separate when they can be separate. Like, if you want to do something that requires changes A and B, then keep A and B separate and explain why A is a good change by itself. Then when A is done, move on to B.
I think this is better even if it might at first sight seem as a "longer path" to where you want to go. Trying to merge the combination A+B directly as a single change would risk more disagreements, even if that (A+B) may be where you are going in the end.
OK let's assume that A by itself causes a problem.
That problem can be solved by merging A+B but then B contains something that some people object to.
Then it might be better to merge A+X where X fixes the problem.
Those who want B will say that B nicely solves the problem so X is not needed. But they should respect that some people are skeptical to the feature Y that is included in B. In this case merge A+X first, then move on to discuss whether or not B should be merged after that.
@eliasr In general, sure, but that's not always possible when A or B by themselves create a problem.