On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber
<git@xxxxxxxxxxxxxxxxxxxx> wrote:
> Felipe Contreras venit, vidit, dixit 02.11.2012 17:09:
>> On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber
>> <git@xxxxxxxxxxxxxxxxxxxx> wrote:
>>> Andreas Ericsson venit, vidit, dixit 02.11.2012 10:38:
>>>> On 11/01/2012 02:46 PM, René Scharfe wrote:
>>>>>
>>>>> 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.
>> 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.
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html