1 |
Rearranging and snipping a bit to clarify my points. |
2 |
|
3 |
On Friday 16 March 2007 09:17, Daniel Drake wrote: |
4 |
> Jason Stubbs wrote: |
5 |
> > 2) Each technical area usually has a clear authority - ie. a spokesman |
6 |
> > whom is listened to and usually has one's posts challenged with clear |
7 |
> > respect. |
8 |
|
9 |
> > 1) There is a fairly clear chain of command. |
10 |
|
11 |
[between those technical areas] |
12 |
|
13 |
> I've seen a few people make this kind of comment recently, and I'm never |
14 |
> sure whether they mean it as it sounds or not. |
15 |
> |
16 |
> What I think people mean to say is that for the major subsystems, there |
17 |
> is a fairly clear structure to the technical contribution flow and the |
18 |
> review process. But there is also a huge amount of code which is not |
19 |
> 'maintained' in this way, where the only realistic patch-target is |
20 |
> Andrew Morton, the lead maintainer of the whole kernel. |
21 |
|
22 |
This is exactly what I meant. |
23 |
|
24 |
> But in my opinion this structure doesn't really relate to the flaming. |
25 |
> |
26 |
> I don't really understand how this relates to the question why linux |
27 |
> kernel flamewars don't appear to harm the kernel community in the way |
28 |
> that gentoo-dev flamewars appear to harm the Gentoo community. |
29 |
|
30 |
Andrew Morton doesn't get involved in the flamewars. From what I've seen, |
31 |
his responses are usually "I don't understand why you are doing this so |
32 |
please explain further", "I think doing it this way would be better than |
33 |
doing it that way" and "I need this, this and this before this patch can |
34 |
move forward". I imagine things work mostly the same in the seperable |
35 |
subsystems too. |
36 |
|
37 |
How does that relate to the difference in flamewar harm? I think that the |
38 |
transparent workflow makes it easy to see that the flamewars have relatively |
39 |
little effect on the amount achieved. I also think that the workflow helps |
40 |
assure users that the flamewars don't affect the end product other than to |
41 |
perhaps delay some specific feature. |
42 |
|
43 |
> Here are my thoughts, and I think there are several answers here: |
44 |
|
45 |
<snip about flamewars leading to uninformed press coverage> |
46 |
<snip about flamewars being driven by people outside the community> |
47 |
|
48 |
Both very good points. |
49 |
|
50 |
> I also feel that the community is more mature, in that people truly with |
51 |
> a grasp on the community generally do not get involved with the heated |
52 |
> discussions when they go beyond the point of technical review. By this I |
53 |
> mean simply: people don't have the apparent urge to respond to mails in |
54 |
> the way that people do here -- kernel developers don't seem to take bait |
55 |
> from trolls. |
56 |
|
57 |
This was what I was trying to get at in the 3rd point of my first email. |
58 |
I probably shouldn't have lumped it under "paid devs", eh? The "urge to |
59 |
respond" problem is probably one of our biggest downfalls here. Not only |
60 |
in taking flamebait though. It is also in replying to a thread that is not |
61 |
really in one's domain - devs acting like users reading uninformed press |
62 |
coverage, if you will. |
63 |
|
64 |
> In general threads also seem to stay on topic more than they do here as |
65 |
> well. Steve Long's initial reply to the thread here didn't add anything |
66 |
> to the discussion Grant was trying to start, and he even admitted so! |
67 |
> I'd say on the LKML replies like this generally don't happen, or if they |
68 |
> do, they get 0 responses. |
69 |
|
70 |
Also part of the "maturity" point. Perhaps we all just need to grow up? ;) |
71 |
|
72 |
> Another factor: think about the level of ratio of developers to users on |
73 |
> both lists. Even if most posts here are by developers, there are a |
74 |
> comparatively large number of non-developer readers, plus the |
75 |
> discussions make good reading material linked from the GWN and forums etc. |
76 |
> |
77 |
> Now look at the LKML. It's often hard to find general discussion behind |
78 |
> the truckloads of patches and river of technical review emails. A large |
79 |
> proportion of the content is not "understandable" unless you have a good |
80 |
> knowledge of C, operating systems, and the technical area in question. |
81 |
> This isn't a place that users hang out, users dont really read it |
82 |
> either, and you need to be a decent developer to get involved in the |
83 |
> first place. |
84 |
|
85 |
This is an important point that I hadn't considered. It kind of resembles |
86 |
the affect of bad press coverage you mentioned earlier. I'm not sure that |
87 |
there's much that can be done about it though - at least not in the short |
88 |
term. |
89 |
|
90 |
Perhaps a code of conduct should be created that discusses how one should |
91 |
behave rather than how one should not. Taking cues from member of LKML that |
92 |
show maturity as well as other communities that do well, it could cover what |
93 |
is expected in the situations where we are failing and extended as needed. |
94 |
What do you think? |
95 |
|
96 |
-- |
97 |
Jason Stubbs |
98 |
-- |
99 |
gentoo-dev@g.o mailing list |