A wild merge request appears. These are your options:

A. Spend 3 days of back and forth
B. Accept MR and fix it yourself later

First is better

First should be better in long run yeah. But sometimes it's just a waste of oxygen to convince others 😆

@WildOrangutan you do not convince. You are the reviewer, you have the power of non-approval.

@iiii Yeah sure, as long as you're the main stakeholder of the project. And I'm pretty sure you're not, so you still have to justify to the actual stakeholder why the change hasn't been approved yet and why you've been spending all that expensive time going back and forth about something they don't directly care about.

You scroll your devrant feed. A @WildOrangutan appears and requests your input on a context-dependant developer dilemma while also triggering your nostalgia for Pokemon. You have no other option but to ++ and leave a comment

Option c approve with suggestions. No back and forth but give the opportunity for correction and proper documentation that if it went south. You also can say I said so!

Outside very temporary crunch time, a MR should not be accepted with the intent of fixing the code later. Merging is acknowledging that the code is as good as it needs to be, and safe to use as the basis of future work.

The literal cost of fixing code can only ever go up after it's merged so this decision is only justifiable if dwlivery is much more valuable now than it'll be in the future.