Rearranging and snipping a bit to clarify my points. On Friday 16 March 2007 09:17, Daniel Drake wrote: > Jason Stubbs wrote: > > 2) Each technical area usually has a clear authority - ie. a spokesman > > whom is listened to and usually has one's posts challenged with clear > > respect.
> > 1) There is a fairly clear chain of command. [between those technical areas] > I've seen a few people make this kind of comment recently, and I'm never > sure whether they mean it as it sounds or not. > > What I think people mean to say is that for the major subsystems, there > is a fairly clear structure to the technical contribution flow and the > review process. But there is also a huge amount of code which is not > 'maintained' in this way, where the only realistic patch-target is > Andrew Morton, the lead maintainer of the whole kernel. This is exactly what I meant. > But in my opinion this structure doesn't really relate to the flaming. > > I don't really understand how this relates to the question why linux > kernel flamewars don't appear to harm the kernel community in the way > that gentoo-dev flamewars appear to harm the Gentoo community. Andrew Morton doesn't get involved in the flamewars. From what I've seen, his responses are usually "I don't understand why you are doing this so please explain further", "I think doing it this way would be better than doing it that way" and "I need this, this and this before this patch can move forward". I imagine things work mostly the same in the seperable subsystems too. How does that relate to the difference in flamewar harm? I think that the transparent workflow makes it easy to see that the flamewars have relatively little effect on the amount achieved. I also think that the workflow helps assure users that the flamewars don't affect the end product other than to perhaps delay some specific feature. > Here are my thoughts, and I think there are several answers here: <snip about flamewars leading to uninformed press coverage> <snip about flamewars being driven by people outside the community> Both very good points. > I also feel that the community is more mature, in that people truly with > a grasp on the community generally do not get involved with the heated > discussions when they go beyond the point of technical review. By this I > mean simply: people don't have the apparent urge to respond to mails in > the way that people do here -- kernel developers don't seem to take bait > from trolls. This was what I was trying to get at in the 3rd point of my first email. I probably shouldn't have lumped it under "paid devs", eh? The "urge to respond" problem is probably one of our biggest downfalls here. Not only in taking flamebait though. It is also in replying to a thread that is not really in one's domain - devs acting like users reading uninformed press coverage, if you will. > In general threads also seem to stay on topic more than they do here as > well. Steve Long's initial reply to the thread here didn't add anything > to the discussion Grant was trying to start, and he even admitted so! > I'd say on the LKML replies like this generally don't happen, or if they > do, they get 0 responses. Also part of the "maturity" point. Perhaps we all just need to grow up? ;) > Another factor: think about the level of ratio of developers to users on > both lists. Even if most posts here are by developers, there are a > comparatively large number of non-developer readers, plus the > discussions make good reading material linked from the GWN and forums etc. > > Now look at the LKML. It's often hard to find general discussion behind > the truckloads of patches and river of technical review emails. A large > proportion of the content is not "understandable" unless you have a good > knowledge of C, operating systems, and the technical area in question. > This isn't a place that users hang out, users dont really read it > either, and you need to be a decent developer to get involved in the > first place. This is an important point that I hadn't considered. It kind of resembles the affect of bad press coverage you mentioned earlier. I'm not sure that there's much that can be done about it though - at least not in the short term. Perhaps a code of conduct should be created that discusses how one should behave rather than how one should not. Taking cues from member of LKML that show maturity as well as other communities that do well, it could cover what is expected in the situations where we are failing and extended as needed. What do you think? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
