On Tue, 2013-07-16 at 14:18 -0700, Paul E. McKenney wrote: > On Tue, Jul 16, 2013 at 10:27:09PM +0400, James Bottomley wrote: > > On Mon, 2013-07-15 at 15:38 -0700, Linus Torvalds wrote: > > > On Mon, Jul 15, 2013 at 3:08 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > > > > > Can we please make this into a Kernel Summit discussion. I highly doubt > > > > we would solve anything, but it certainly would be a fun segment to > > > > watch :-) > > > > > > I think we should, because I think it's the kind of thing we really > > > need at the KS - talking about "process". > > > > Can you formulate the process issue to discuss? I've heard "Linus needs > > to yell less at people" and "the mailing lists need to be more > > 'professional'" neither of which seems to identify an actual process. > > Are we perhaps discussing guidelines for giving feedback on patches? > > > > > At the same time, I really don't know what the format would possibly > > > be like for it to really work as a reasonable discussion. And I think > > > that is important, because this kind of subject is *not* likely > > > possible in the traditional "people sit around tables and maybe > > > somebody has a few slides" format. > > > > > A small panel discussion with a few people (fiveish?) that have very > > > different viewpoints, along with baskets of rotten fruit set out on > > > the tables? That could be fun. And I'm serious, although we might want > > > to limit the size of the fruit to smaller berries ;) > > > > How about Lychees? They're prickly on the outside, very wet on the > > inside and have large stones ... > > They taste good, too. > > > But what are the viewpoints? "maintainers need to yell more"? > > "maintainers need to yell less"? I don't think I agree with either. > > I'm perfectly happy to run linux-scsi along reasonable standards of > > civility and try to keep the debates technical, but that's far easier to > > do on a low traffic list; obviously, I realise that style of argument > > doesn't suit everyone, so it's not a standard of behaviour I'd like to > > see universally imposed. In fact, I've got to say that I wouldn't like > > to see *any* behaviour standard imposed ... they're all basically cover > > for power plays (or soon get abused as power plays); the only real way > > to display leadership on behaviour standards is by example not by fiat. > > OK, I am stupid enough to take a stab at this... > > 1. Does the Linux kernel community's health depend on the occasional > rant? [My guess is that we simply have no way of knowing. > That said, I would be interested in hearing specific examples > of open-source communities that are as doing as well as is the > Linux community and that live within stricter social mores. > Cue arguments about exactly what "doing well" means...] > > 2. Could the Linux kernel community's health be improved by banning > the occasional rant? [Again, I don't believe that we have any > way of knowing.] > > 3. Is there some reasonable way to accommodate a wide range of > styles of interaction within the Linux community? [I hope that > the answer is "yes", but it probably becomes impossible if you > add the qualifier "that everyone is happy with".] > > 4. If there is some reasonable way to accommodate a wide range > of styles of interaction within the Linux community, can this > be done globally, or does this require that people who prefer a > specific style confine themselves to portions of the community > that practice that specific style? [As I grow older, I become > increasingly pessimistic about the possibility of keeping everyone > happy, but who knows?] > > For whatever it is worth... Well, you have friends in acadaemia, perhaps there might be an interesting study here. If you consider the management style of the kernel, does it enable contributions from a broader range of people than would be tolerated in industry? Industry has a problem with what managers like to call "brilliant jerks" people who have a well recognised talent but who cannot be controlled (at least by the aforementioned managers) and become corrosive to the team (do we actually manage to make use of these people in the kernel?). They also tend to have a problem at the bottom end: those who are just about OK at their jobs; certainly not bad enough to be fired but whom they'd dearly love to replace with better workers (does the attitude in the kernel tend to discourage these types?) It's probably less relevant to the discussion at hand, but I'd be curious to see the results. Assuming they say that we do have a higher output per developer, the next study could investigate why this is ... James -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html