From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f198.google.com (mail-wr0-f198.google.com [209.85.128.198]) by kanga.kvack.org (Postfix) with ESMTP id D043B800D8 for ; Thu, 25 Jan 2018 05:02:12 -0500 (EST) Received: by mail-wr0-f198.google.com with SMTP id v10so4118073wrv.22 for ; Thu, 25 Jan 2018 02:02:12 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id z192si607440wmc.251.2018.01.25.02.02.11 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 25 Jan 2018 02:02:11 -0800 (PST) Date: Thu, 25 Jan 2018 11:02:10 +0100 From: Jan Kara Subject: Re: [LSF/MM TOPIC] Patch Submission process and Handling Internal Conflict Message-ID: <20180125100210.fqyj2uuoktiwbcus@quack2.suse.cz> References: <1516820744.3073.30.camel@HansenPartnership.com> <1516821978.3987.8.camel@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516821978.3987.8.camel@wdc.com> Sender: owner-linux-mm@kvack.org List-ID: To: Bart Van Assche Cc: "linux-scsi@vger.kernel.org" , "James.Bottomley@HansenPartnership.com" , "linux-mm@kvack.org" , "linux-fsdevel@vger.kernel.org" , "lsf-pc@lists.linux-foundation.org" On Wed 24-01-18 19:26:20, Bart Van Assche wrote: > On Wed, 2018-01-24 at 11:05 -0800, James Bottomley wrote: > > 2. Handling Internal Conflict > > > > My observation here is that actually most conflict is generated by the > > review process (I know, if we increase reviews as I propose in 1. we'll > > increase conflict on the lists on the basis of this observation), so > > I've been thinking about ways to de-escalate it. The principle issue > > is that a review which doesn't just say the patch is fine (or fine > > except for nitpicks) can be taken as criticism and criticism is often > > processed personally. The way you phrase criticism can have a great > > bearing on the amount of personal insult taken by the other party. > > Corny as it sounds, the 0day bot response "Hi Z, I love your patch! > > Perhaps something to improve:" is specifically targetted at this > > problem and seems actually to work. I think we could all benefit from > > discussing how to give and receive criticism in the form of patch > > reviews responsibly, especially as not everyone's native language in > > English and certain common linguistic phrasings in other languages can > > come off as rude when directly translated to English (Russian springs > > immediately to mind for some reason here). Also Note, I think fixing > > the review problem would solve most of the issues, so I'm not proposing > > anything more formal like the code of conflict stuff in the main > > kernel. > > > > We could lump both of these under a single "Community Discussion" topic > > if the organizers prefer ... especially if anyone has any other > > community type issues they'd like to bring up. > > Hello James, > > How about discussing the following two additional topics during the same or > another session: > * We all want a concensus about the code and the algorithms in the Linux > kernel. However, some contributors are not interested in trying to strive > towards a concensus. If some contributors e.g. receive a request to rework > their patches, if they don't like that request and if the reviewer is > working for the same employer sometimes they try to use the corporate > hierarchy to make the reviewer shut up. I think this is behavior that works > against the long-term interests of the Linux kernel. Well, it probably is but using corporate hierarchy to make reviewer shut up is a problem of that corporation. So if particular examples are brought to LF TAB attention maybe they could apply some pressure but that's all. In the end it is a company internal thing. Change your boss / employer if they do stuff like this to you. E.g. I personally never experienced anything like this. > * Some other contributors are not interested in achieving a consensus and do > not attempt to address reviewer feedback but instead keep arguing or do what > they can to insult the reviewer. Yes, then I think it is up to the maintainer to weight in with his opinion... Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org