On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber <g...@drmicha.warpmail.net> wrote: > Felipe Contreras venit, vidit, dixit 02.11.2012 17:09: >> On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber >> <g...@drmicha.warpmail.net> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html