It’s Sunday. You’ve had a lovely afternoon of coding and you’ve just submitted a pull request. Unfortunately, your enjoyment quickly vanishes when someone you don’t even know, leaves numerous review comments all over your work! (assuming you are lucky enough to have your unsolicited PR even noticed, that is). All those review comments cloud your thinking, and your peaceful Sunday goes up in smoke.
How should you respond to the (insert expletive here) reviewer?
You might be technically right in your decisions, but a combative response never fairs well, especially when you don’t know the other person. However, implementing every requested change might be a time consuming ‘ball ache’, or worse, fury causing if you feel the requested changes are inferior to your original contribution.
Perhaps the reviewer knows something you don’t, or perhaps they haven’t actually done a decent review; either way, a follow-up discussion could be appropriate. But how do you broach the topic without coming across as arrogant or combative? Sometimes other contributors just want it done ‘their way’, and you must comply for no other reason than being ‘lower down the contributor hierarchy’. Are you willing to take direction from someone you don’t know, and possibly don’t even agree with?
We’ve all had spats at work, so I won’t expand on that except to say that disagreements between open source developers are even harder to resolve than with work colleagues. Sometimes, you can ‘argue your case’, but that often depends on earned trust, which means you’ll need to stick around for a while first. This may be tolerable when your livelihood is at stake, but will you ‘suck it up’ when you aren’t getting paid?
Many people simply walk away at this point. Others stay and fight on the internet for a while. Far fewer get their contribution accepted. This is why getting an open source contribution accepted can be way more challenging than you might think.
Better Software UK specialises in software requirements for Legacy System Replacement 🔥; particularly for remote, outsourced and offshore development teams working in financial services.