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

[<zeurkous@xxxxxxxx>]

Haai,

"Marlon" <marlon.richert@xxxxxxxxx> wrote:
>Hi, all!
>
> After writing workers/48583,

Disclaimer: didn't read that. Should me?

> 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.

A work tends to inherit some (many?) of the creator's characteristics,
though. And devastating criticism can be easily given without malice.

The flip side of the latter is that lavish praise can be given without
good feelings on the part of the praiser.

Me's new here (obviously), but to me, it's actually a relief that toes
do not appear to be easily stepped on. That's different in much of the
{,``OSS'' }world. Me*thinks* me knows why, but that would appear to be
beyond the scope of this discussion.

> 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.

Cultural norms vary from place to place -- otherwise it wouldn't be
culture. Are you suggesting that the cultural norm on this list be
changed...? 

> 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.

Rude? You know what's rude? "Don't see the point, sorry.". Or
purposefully ignorning trivial patches to obvious problems, even after n
pings. Or mud-slinging them (not even bothering to make a good flame)
because the author isn't liked. Or shunning a contributor 'cause he
can't help but point out larger issues along the way, issues too big for
them to chew. All of that, and more, has happened to me. And rest
assured me's not the only one.

Again, there's a flip side: fluffy and sweet coders, who may've followed
a course in coding or two, but have no idea how to program, let alone
how to communicate about programming. Many of those mantain projects,
perhaps even projects that you and me depend on. Me'd argue that's no
good, either. Some ballast is needed.

Now, me's not going to stick too many feathers up the butt of a person
me's only exchanged a couple of msgs with, yet... compared to the above
attiudes, the "friendly, to-the-point" style of Daniel is
$DEITY_RESIDENCE to me.

That leaves me to wonder if the "do your homework" bit is what ticked
you off in particular.

> 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.

Most self-declared "techies" *are* primadonnas and crybabies.
$UNDEITY_RESIDENCE, even many of those that *are* actually competent,
are successfully running major projects, and are generally safe and
secure in their current social position, act that way.

Me supposes they're just lusers in disguise.

>> [...]
>> 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.

As me's more than hinted at above: code is often an extension of its
creator. Even if the reviewer can make the distinction, the creator
often can't. The reality is that many creators have long toes, but that
makes them just as responsible for implementing the obvious workaround:
"Keep a little distance.".

> 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. ;)

That's great, but please, next time when you quote from a WWW page, do
fold(1) the paragraphs.

Take care,

        --zeurkous.

-- 
Friggin' Machines!