[Phlebsy]

There are two ways I've found success where I've come into a team with these issues:

1. Differentiate critical comments vs opinions/nice to haves. Not every comment needs to be resolved as part of that specific PR, they can be addressed in a follow up after it is merged in a disciplined team.

2. Be okay with reviewers contributing to the PR themselves. Some developers just get too caught up on 'ownership' of code that makes it in, when the team is responsible for it in the end(when you have a blameless/improvement focused culture at least). I don't need the original branch owner to fix a typo or nitpicks when it will take me less time to fix it. I haven't found any code suggestion features that are amazing for this, so sometimes you'll end up with back/forth disagreement and have to rebase a commit out, but most of the time it's fine and overall improves velocity. Basically turning the PR into async pair programming.

[teqsun]

Fair. I guess I've found that in my encounters, personally doing everything proper for other's code reviews hasn't inspired change in the other developers to reciprocate.

i.e. I haven't walked into an environment with a lacking PR culture and managed to effect a cultural change (yet). Maybe seniority is a prerequisite?

[thehappyfellow]

It’s big, particularly the second point. I fix typos and obvious mistakes while reading the code and I leave „feel free to punt” on any comment which shouldn’t block release.

Still, bikeshedding occurs but to a lesser degree and over more substantial issues, like overall module design.