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

[Bart Van Assche <Bart.VanAssche@wdc.com>]

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.
* 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.

Thanks,

Bart.