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@xxxxxxxx> SUSE Labs, CR -- 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>
