I have opened pull request to the academic project, developed as a joined effort of few universities, and received numerous comments. They are all from the single reviewer that seems to be one of the lead developers.

Some of these comments are clearly "opinion based" and I could generally find arguments to say against. But doing as they want would also result a working code. Opinions only diverge on which version is more understandable and maintainable. I am also experienced, same as they are.

The possible approaches seem to be

  • Comment on items I disagree with and do not apply changes to them. Of course, if they just refuse to merge without further talk, I am also with the loss.
  • Apply all changes they like but explain why it was initially done differently.
  • Do not comment, simply apply all changes as they see fit. This is my first contribution after all, I may better discuss on something later.

My goal is to earn the respect within that community and ultimately contribute more code to them. To achieve this goal, I am willing to comply with they point of view even if I myself think differently or my own experience just talks against.

Would a small amount of opposition help or hinder the attempts to build the respect? I do not want to provoke the conflict, but silent agreement might incorrectly indicate I am not competent enough to join the community (for the simplicity, let's assume I am).

  • 1
    This seems to be about how to compromise. In the coding world, especially if your not the owner of the code base, you will have to give more often than not. – Mister Positive Dec 7 '17 at 13:01
  • 1
    Working well with others is not about agreeing on everything, but rather about mainly discussing important things and agreeing to disagree and compromising on everything else. – Dukeling Dec 7 '17 at 13:03
  • 1
    How do your arguments differ from "opinion-based"? – dvc.junior Dec 7 '17 at 13:16
  • "Opinion based" means all questions relevant to the features addressed are closed as "primarily opinion based" on software engineers Stack Overflow. Also, the code review does not provide any arguments, just shortly states that is wrong. – eee Dec 7 '17 at 13:25
  • 1
    @eee Sure. I know that. I didn't ask you that. Let's go again. "Some of these comments are clearly "opinion based" and I could generally find arguments to say against". How do your arguments against differ from "opinion-based"? – dvc.junior Dec 7 '17 at 13:30

Would a small amount of opposition help or hinder the attempts to build the respect?

It seems as though you're in a situation where on occasion there are multiple ways to accomplish the goal with no clear cut "This is the only answer".

When coding, especially if you're not the owner but more of a contributor, you are going to have to be more flexible with your approach, and conform to the style/standards in place with a particular code base.

It certainly is okay to say "Did you consider this aspect?", but in the end if you want your contribution accepted, you may have to alter your style.

Short answer: If you have a legitimate point of view, make it known. The other side cannot always be right, and you should get some wins too. If you do not get some of your "wins", then you may wish to consider contributing elsewhere.

  • 1
    +1 for the alternate choices or backup of why your choice and theirs differ. My boss and I have had conversations that go "Why didn't you do it this way, we've always done it this way" that I then respond to with "because this, this and this", and we go from there. Sometimes we agree with his way, sometimes with mine, but we always come away with some more information than we started with. – SliderBlackrose Dec 7 '17 at 14:34

I've always been a lone, full-stack developer for small organizations, so my opinion probably counts for less since there is no collaborative code review process when it's just me. However, wouldn't another approach be -

Apply all non-contested changes, and explain why original methods were used, and see if that changes any opinions as to whether the contested suggestions are needed. Ask parties involved other than OP and that one particular developer suggesting all the changes to make the final determination on whether to maintain status quo or change.

NOTE: I was also a continuous improvement team facilitator in a past professional life, so there is a little bit of group/consensus decision-making experience that goes into that suggestion.


In these types of matters, you should pick your battles. Itemize major items you're concerned with and offer alternatives. Provide strong arguments and your reasoning. Let them know when you would be available to discuss and how to connect with you (Skype/Phone) if lines of communication haven't been established.

Go along with the rest and let them know you'll bring up any concerns if these turn into trouble. Offer to provide your reasoning if they wish. This way, you don't look defensive.

Not the answer you're looking for? Browse other questions tagged or ask your own question.