> This particular patch seems especially important to the developer who submitted it. (Maybe they said that outright, as part of their argument trying to persuade you to take the patch. Or maybe you just read between the lines.)
> But this patch isn’t especially vital to you – so you’re in a position of power! Now you can hold the change they need hostage until they do lots of extra tangentially related work, which doesn’t really need to be in the same commit, but which is important to you.
The reviewer outright denies this occurs, and it occurs every time.
For a commit on changing the documentation, he will then want the entire documentation redone, including pages that aren't being changed.
And will refuse to approve it until every issue he's brought up has been addressed.
I've just stopped asking them for PR reviews, and ask other teams to review my PRs.
I've been guilty of this too, and generally I'll write something along the lines of "this would be nice to do, but it's out of scope unless you want to take it on".
My issue is, if you want other things done, make issues for them. Don't try to address every single thing you don't like, that is remotely around the code I am trying to get this fix in for.
Like, he has great feedback. It's not the quality of the feedback or content, it's that it has nothing to do with what I currently need urgently implemented to fix a problem.
I‘ve had a platform lead constantly try ransoming small refactorings into feature PRs, because he found out that’s the only way of achieving continuous architectural improvements. (Medical product, so the process was rigid)
No, but I don't go to management to handle personal issues. I just handle them. When you go to management, you have to accept management's decision. When you just make decisions, you get autonomy.
The Ransom Note
> This particular patch seems especially important to the developer who submitted it. (Maybe they said that outright, as part of their argument trying to persuade you to take the patch. Or maybe you just read between the lines.)
> But this patch isn’t especially vital to you – so you’re in a position of power! Now you can hold the change they need hostage until they do lots of extra tangentially related work, which doesn’t really need to be in the same commit, but which is important to you.
The reviewer outright denies this occurs, and it occurs every time.
For a commit on changing the documentation, he will then want the entire documentation redone, including pages that aren't being changed.
And will refuse to approve it until every issue he's brought up has been addressed.
I've just stopped asking them for PR reviews, and ask other teams to review my PRs.