I've got two community style topics, which should probably be discussed in the plenary 1. Patch Submission Process Today we don't have a uniform patch submission process across Storage, Filesystems and MM. The question is should we (or at least should we adhere to some minimal standards). The standard we've been trying to hold to in SCSI is one review per accepted non-trivial patch. For us, it's useful because it encourages driver writers to review each other's patches rather than just posting and then complaining their patch hasn't gone in. I can certainly think of a couple of bugs I've had to chase in mm where the underlying patches would have benefited from review, so I'd like to discuss making the one review per non-trival patch our base minimum standard across the whole of LSF/MM; it would certainly serve to improve our Reviewed-by statistics. 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. James
