Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper

On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber
[off-list ref] wrote:

Felipe Contreras venit, vidit, dixit 02.11.2012 17:09:

quoted

On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber
[off-list ref] wrote:

quoted

Andreas Ericsson venit, vidit, dixit 02.11.2012 10:38:

quoted

On 11/01/2012 02:46 PM, René Scharfe wrote:

quoted

Also, and I'm sure you didn't know that, "Jedem das Seine" (to each
his own) was the slogan of the Buchenwald concentration camp.  For
that reason some (including me) hear the unspoken cynical
half-sentence "and some people just have to be sent to the gas
chamber" when someone uses this proverb.

It goes further back than that.

"Suum cuique pulchrum est" ("To each his own is a beautiful thing") is
a latin phrase said to be used frequently in the roman senate when
senators politely agreed to disagree and let a vote decide the outcome
rather than debating further.

Please don't let the twisted views of whatever nazi idiot thought it
meant "you may have the wrong faith and therefore deserve to die, so you
shall" pollute it. The original meaning is both poetic and democratic,
and I firmly believe most people have the original meaning to the fore
of their mind when using it. After all, very few people knowingly quote
nazi concentration camp slogans.

In fact, many German terms and words are "forbidden area" since Nazi
times, but I don't think this one carries the same connotation.

But that is a side track.

Collaboration (and code review is a form of collaboration) requires
communication. The linked code of conduct pages describe quite well how
to ensure a productive environment in which "everyone" feels comfortable
communicating and collaborating.

Yes, but that's assuming we want "everyone" to feel comfortable
communicating and collaborating.

I put "everyone" in quotes because you can never reach 100%, so
"everyone" means almost everyone.

Undeniably, the answers in this and the other threads show that on the
git mailing list, "everyone" wants "everyone" to feel comfortable
communicating and collaborating.

And that might be a mistake. Because "everyone" doesn't include the
people that are able to put personal differences aside, and
concentrate on technical merits.

quoted

I cite again the example of the Linux
kernel, where certainly not "everyone" feels that way. But somehow

It's a different list with different standards and tone, so it doesn't
really matter for our list. That being said:

If you don't want to take into consideration what the most successful
software project in history does... up to you.

quoted

they manage to be perhaps the most successful software project in
history. And I would argue even more: it's _because_ not everyone
feels comfortable, it's because ideas and code are criticized freely,
and because only the ones that do have merit stand. If you are able to
take criticism, and you are not emotionally and personally attacked to
your code and your ideas, you would thrive in this environment. If you
don't want your precious little baby code to fight against the big
guys, then you shouldn't send it out to the world.

For one thing, contributors on the kernel list are open to technical
arguments, and that includes the arguments of others; just like we are
here. On the other hand, you seem to rebuke "any" (most) technical
argument in harsh words as if it were a personal attack; at least that's
how your answers come across to me (and apparently others). That really
makes it difficult for most of us here to argue with you technically,
which is a pity. That lack of openness for the arguments of others would
make your life difficult on the kernel list also.

It doesn't. And I don't.

There is no lack of openness from my part. I hear all technical
arguments, and I reply on a technical basis. The problem seems to be
is that you expect the code submitted to be criticized, but not the
criticism it receives. IOW; the submitter has to put up with anything
anybody says about his/her code and ideas, but the *reviewer* is
untouchable; the submitter cannot ever criticize the reviewer. I can
tell you that doesn't happen in the Linux kernel; the review process
is a _discussion_, not a one-way communication, and discussions can be
heated up, but the end result is better code, *both* sides are open to
criticism, the submitter, *and* the reviewer.

It seems to me that you think in the git mailing list the submitter
should never put in question the criticism of the reviewer.

If that's not the case, show me a single instance when I rebuke
technical arguments in *harsh* words... perhaps, you think any
rebuking is "harsh". Specifically, show me an instance were *I* was
harsh, and the reviewer was not.

If you cannot show instances of this, then your statement that I
rebuke harshly doesn't stand; I rebuke, that's all.

A completely different issue is that of language. You talk German on a
German list and English on an international list. You talk "kernel
English" on the kernel list, which is full of words and phrases you
would never use in a normal social setting where you talk to people in
person; it would be completely unacceptable. Here on the Git list, we
prefer to talk like in a normal, albeit colloquial social setting. If
you're open for advice: just imagine talking to the people here in
person, to colleagues across your desk, and you have a good guideline.

If a submitter cannot rebuke, why would I want to contribute to such a
project? If we cannot speak openly why would I want to contribute?

I wouldn't.

And no, using the same or similar language does not make us the same at
all. Using the same language is the natural prerequisite for successful
communication.

Nobody said otherwise.

Felipe, please try to see the efforts many of us are making here in
order to keep you as a contributor, and reward it by accepting the
advice to revise your language: colleague to colleague.

Thanks, but no thanks. I contribute on my free time, and if
contributing is not a fun process, why would I?

It seems to me that you feel you are not only entitled to my code, but
to never criticize back. I've seen this happen multiple times now,
when I send patches, which are a *contribution*, and the reviewers
expect me to address every and all issues they raise without
criticizing back, or that somehow it's my *responsibility* to address
their concerns, even if I don't agree. I'm sorry but it's not.

In a truly technical project code speaks, and if you as a reviewer
feel something has to be changed, and the submitter (which is acting
on his/her own volition and free time) is not willing to do it, he/her
himself/herself can take the code and do whatever modifications to it,
or the commit message, seem necessary. *Not* to keep bashing the
submitter until they do it exactly as they want as if somehow it was
their *responsibility*.

The spirit of open source is *collaboration*, and what you seem to
expect here is that I do everything. Not only do I have to come up
with the code, I have to come up with a full book chapter of commit
message explaining all the history and introducing how the code works
to people unfamiliar with it, and I have to hear review criticism
without arguing back, and I have to implement it even if I disagree,
and I have to be careful about what every word I say might be taken by
people from other cultures (but they don't), and I can never say
anything that might under certain circumstances and assumptions be
considered offensive (even though they can). And never criticize back
the hidden guidelines.

This is not collaborative, this only ensures that you will get a very
specific kind of contributors.

If what you want is a closely-knitted circle of friends that are
like-minded, then this seems like the right approach.

If what you want is to have a good project, with good code, it might not.

Cheers.

-- 
Felipe Contreras