On Wed, 2018-01-24 at 19:26 +0000, 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. Trying to intimidate people into doing what you want is a well known social tool. The particular problem here is that it's the corporate power structure that's used to effect the intimidation. That's pretty much outside of our control (unless we work for the same company), so there's not much we can do to stop it except say you shouldn't try to intimidate reviewers. I suppose one practical policy could be demanding reviews from independent (meaning outside the corporate power structure) people. > * 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. Well, I think this fits neatly in the giving and receiving and receiving criticism bucket. The first rule of interacting with others is "never attribute to malice something which could possibly be accidental". In the end it's up to the maintainer to arbitrate based on their opinion of the merits of the review. James -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
