Re: [LSF/MM TOPIC] Patch Submission process and Handling Internal Conflict

[Jan Kara <jack@suse.cz>]

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 <jack@suse.com>
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>