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 <[email protected]>
SUSE Labs, CR
