[META] Tone of voice / Writing style in patch reviews (was Re: Patch bumping)

[Marlon <marlon.richert@gmail.com>]

Hi, all!

On 13 Apr 2021, at 21:08, Lawrence Velázquez <larryv@zsh.org> wrote:
> On Apr 13, 2021, at 8:32 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>> Leaving #4 "considerably longer" would decrease temporal locality in the
>> patch authors' brains, would reap less "the project noticed my lack of
>> response" benefits (cf.
>> https://producingoss.com/en/managing-participants.html#delegation-followup),
>> and would be more likely to find the patch author busy with other things
>> and unable to follow up and post a revised patch.
> 
> Good point.

After writing workers/48583, I would like to add something to this that I think is even more important for keeping new contributors motivated to stay engaged (from the same resource as above):

From [Praise and Criticism](https://producingoss.com/en/managing-participants.html#praise-and-criticism):
> An important feature of technical culture is that detailed, dispassionate criticism is often taken as a kind of praise (as discussed in the section called “Recognizing Rudeness”), because of the implication that the recipient's work is worth the time required to analyze it. However, both of those conditions — detailed and dispassionate — must be met for this to be true. For example, if someone makes a sloppy change to the code, it is useless (and actually harmful) to follow up saying simply "That was sloppy." Sloppiness is ultimately a characteristic of a person, not of their work, and it's important to keep your reactions focused on the work. It's much more effective to describe all the things wrong with the change, tactfully and without malice.

From [Recognizing Rudeness](https://producingoss.com/en/you-are-what-you-write.html#rudeness):
> So what is rude?
> 
> By the same principle under which detailed technical criticism is a form of flattery, failure to provide quality criticism can be a kind of insult. I don't mean simply ignoring someone's work, be it a proposal, code change, new ticket filing, or whatever. Unless you explicitly promised a detailed reaction in advance, it's usually okay to simply not react at all. People will assume you just didn't have time to say anything. But if you do react, don't skimp: take the time to really analyze things, provide concrete examples where appropriate, dig around in the archives to find related posts from the past, etc. Or if you don't have time to put in that kind of effort, but still need to write some sort of brief response, then state the shortcoming openly in your message ("I think there's a ticket filed for this, but unfortunately didn't have time to search for it, sorry"). The main thing is to recognize the existence of the cultural norm, either by fulfilling it or by openly acknowledging that one has fallen short this time. Either way, the norm is strengthened. But failing to meet that norm, while at the same time not explaining why you failed to meet it, is like saying the topic (and those participating in it) was not worth much of your time — that your time is more valuable than theirs. Better to show that your time is valuable by being terse than by being lazy.

I know I am new to this project, but I found Daniel's tone of voice/writing style in workers/48571 quite rude, both on a personal level and according to the definition above. Let’s not treat each other like this, shall we? Just point out why and how you think I should fix the mistakes I make, and I will be happy to oblige. But if you neither explain _why_ what I did was wrong nor _how_ I should fix it, then your feedback is neither constructive nor actionable.

Finally, I would like to quote two points from [The 10 Commandments of Egoless Programming](https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/):
> 5. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
> […]
> 10. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code.


Kind regards,
—Marlon

PS: Look, I even fixed the indentation of my quote attribution lines for you, Daniel, in this email. You can’t say I don’t listen. ;)