[davidrm]

> Ask, don’t tell. (“What do you think about trying…?” rather than “Don’t do…”)

When I led a team of 6 people, I did the opposite. The guideline was to always use the imperative form if you knew there was a better way, especially if there's a precedent or it's a written rule in a guideline, but even for opinionated things.

It resulted in clear debate in PRs, ZERO personal conflicts, everything was very civil and productive.

I'm just mentioning this as a personal anecdote, not suggesting that there's a right or wrong way. The reason this worked in my team is because we were, and still are - a team. They're still doing it like that even though I'm no longer involved in day to day.

[madeofpalk]

Granted this is from my experience of working in in-house dev teams (rather than say open source contributions), but very often I find there is no single objective right way to do something, certain things are just subjective opinions, and I'm not going to pretend that after looking at a PR on GitHub.com, that I know more than the person working on it (of course, there are exceptions, but this is what I find to be true generally).

If I see something that looks wrong, my assumption is that I'm missing some kind of knowledge or context that lead to the way for the code to be written the way it is. So I ask questions or offer suggestions or my thoughts. I'm definitely not going to tell someone to do something.

But at the end of the day, very rarely do I see something that should be a critical blocker for a piece of work, so I'll share my thoughts, approve, and leave it to the perfectly capable original submitter to do with that what they want.

[hcarvalhoalves]

I agree.

It shouldn't disguise as a question if you're not really inviting a debate, doesn't feel honest IMO. When the imperative form is used the reader will often assume you know something they don't, and only argue when they see a problem or want to validate the assumption.

I believe the more the comments (annotations?) are about the code itself ("This should do X", "This is not doing Y") rather than a back-and-forth conversation ("What do you think about X?", "Have you thought about X?"), the less personal it feels, and the more the ego gets out of the way.

Same thing for denying PRs with "request changes" - I've had a few people say they avoid doing it because it feels aggressive, but knowing there's a problem and still letting it into production (and then have the PR author fix a much more costly mistake) isn't honest or professional.

[ProZsolt]

> the less personal it feels, and the more the ego gets out of the way.

That's why I usually use "We should do this" instead of "You should do this", and "Our code" not "Your code" because we are a team and we do this together.

I have no problem denying PRs or if somebody do this with mine. If we can't get to the same page, we just call the tech lead to break up the tie.

[auiya]

This can be culturally biased as well. I find European groups tend to be more assertive where as east Asian groups definitely don't use imperative forms as a matter of course. I think the takeaway is to always consider the audience for which you're writing.

[m90]

> The guideline was to always use the imperative form

Has this team been distributed in some way or did it consist of people that have regular in-person interaction?

[davidrm]

The entire team is within a 2 meter radius :)

There are other teams within the department which are distributed in a total of 4 cities inside the same country (a sort of "hub and spoke") and with SOME of these teams, because they collaborate and communicate often, this candid communication works well.

[datanerd]

> The guideline was to always use the imperative form if you knew there was a better way, especially if there's a precedent or it's a written rule in a guideline, but even for opinionated things.

Same here. We used imperative form too and never had any problems. All developers were matured enough to not take comments about technical stuff personally. I think as long as we are being direct and polite in the reviews, there should be no issues.