1 |
On 2/2/08, Jan Bilek <clonolu@×××××.com> wrote: |
2 |
> On Thu, 2008-01-31 at 10:24 -0800, Chris Gianelloni wrote: |
3 |
> > OK, I'm starting a new thread here to try to discuss some things the |
4 |
> > trustees can do to improve both visibility and also attempt to |
5 |
> > ensure/promote progress within the Foundation. Please chime in with |
6 |
> > your own ideas. |
7 |
> > |
8 |
> > - Regular meetings - The trustees should have a regular monthly meeting |
9 |
> > to discuss progress, preferably the first week of the month (for GMN). |
10 |
> > |
11 |
> > - Regular GMN section - I think that both the Council and the trustees |
12 |
> > should have a section each for summaries of their latest meetings. This |
13 |
> > should relay information about what is happening to the developer pool |
14 |
> > and the community, in general. |
15 |
> > |
16 |
> > - Named positions - I also think that specifically putting certain |
17 |
> > people into certain positions would possibly improve getting things |
18 |
> > done. For each position, there should be an alternate, so that we don't |
19 |
> > end up relying on a single person. This also breaks up the |
20 |
> > responsibilities a bit so that the trustees and the community know what |
21 |
> > responsibilities that each person should be working. Positions that I |
22 |
> > see that could/should be filled: President, Secretary, Treasurer |
23 |
> > |
24 |
> > Those are my initial ideas. Comments? |
25 |
> > |
26 |
> |
27 |
> I am not a developer, just user, but I hope I can dare to express my |
28 |
> opinion - I read these nice ideas about improving communication |
29 |
> between developers and users and I think it's also up to us - users... |
30 |
> so I am trying. |
31 |
> |
32 |
> I have grown up in a centrally planned economy and it was all about |
33 |
> regular meetings, summaries and named positions - those were used as |
34 |
> tools to improve things and they almost never worked as expected. |
35 |
> |
36 |
> For example these regular meetings you propose - if there is an issue |
37 |
> to talk about why wait until the regular meeting is held? Are there no |
38 |
> efficient and easy to use channels to communicate immediately? If |
39 |
> there is no issue to talk about - regular meeting would be just a |
40 |
> waste of time. |
41 |
|
42 |
Meetings are for decisions. Decision making is poor on a mailing list |
43 |
and it is not a great idea to make decisions by oneself in a vacuum. |
44 |
Meetings should have topics ahead of time and the people in the |
45 |
meeting should have done their homework on those topics prior to the |
46 |
meeting. Otherwise the meeting is pointless; as you have no doubt |
47 |
noticed when a meeting is run poorly. |
48 |
|
49 |
> |
50 |
> These institutional things make everything less efficient - and BTW - |
51 |
> they tend to get sooo boring and meaningless... The more non-formal, |
52 |
> immediate and 'not institutionalized' communication - the better. |
53 |
> |
54 |
> In (obviously not just) my opinion the problem is that Gentoo has |
55 |
> become too political, too rigid, too bureaucratic and institutional - |
56 |
> and it seems to me that maybe you don't realize (maybe you have not |
57 |
> attended as many regular meetings as I have;-)) that you want to fix |
58 |
> things by making Gentoo even more bureaucratic, more institutional, |
59 |
> less flexible. |
60 |
|
61 |
Where? Be specific in pointing out where you think policy/regidness |
62 |
is holding back development. |
63 |
|
64 |
> |
65 |
> I think the solution is to go the exact opposite way - to make |
66 |
> structural changes and use technical tools (as Daniel Robbins wrote |
67 |
> about it) that would allow Gentoo to become more decentralized, |
68 |
> flexible, less formal, less political. Disassembling the cathedral a |
69 |
> little. |
70 |
> |
71 |
> Competition of smaller projects led by developers who talk when they |
72 |
> need to instead of cathedral led by official institutions going |
73 |
> through official (and less and less efficient) ways. Smaller teams who |
74 |
> communicate on daily basis so they don't need summaries and reports. |
75 |
|
76 |
I think we have more of this than you know; it's just not visible. If |
77 |
dozens of small teams are talking you only know about it when you are |
78 |
on the dozens of teams. This has always been the case (I used to try |
79 |
to be that guy who was on the majority of teams and tried to |
80 |
co-ordinate with many of them; it's a tough job). |
81 |
|
82 |
> |
83 |
> Allowing and promoting funny competition between smaller teams instead |
84 |
> of demotivating (because unsolvable) fights inside huge teams frozen |
85 |
> in official ways of doing things. I have seen many developers leaving |
86 |
> Gentoo because of fights - is it necessary? There should be some way |
87 |
> to use the conflict for Gentoo's sake and developers' fun instead of |
88 |
> never-ending discussions with only one solution - less patient side of |
89 |
> a dispute leaves Gentoo. |
90 |
> |
91 |
> Discussions are good but sometimes when there is too much of a need to |
92 |
> discuss things this tells us that there is something wrong and there |
93 |
> is a need for structural change. I think Gentoo needs mechanism for |
94 |
> teams to split up much more easily - I mean... lets let the work do |
95 |
> the talking - if there is a disagreement in a team they should be able |
96 |
> to split up easily and compete - the better technical solution wins |
97 |
> and gets to the official tree - that's IMO more efficient and more fun |
98 |
> way than discussions. I have some kind of micro-forks inside Gentoo on |
99 |
> mind - I think that is what Gentoo should support as much as possible |
100 |
> and Gentoo's infrastructure should be tailored to support it. |
101 |
|
102 |
You can't fork every disagreement; at which point does a disagreement |
103 |
become important enough for a fork? Why are individuals so stubborn |
104 |
that they cannot compromise? Also, better technical solutions don't |
105 |
always win, with Gentoo and in the world at large. Certainly we could |
106 |
attempt to change this internally; but I wonder if everyone would |
107 |
enjoy the costs. |
108 |
|
109 |
Our 'infrastructure' if I take your meaning properly is limited in |
110 |
scope. We can't have tons of rsync trees with gentoo-x86 checkouts |
111 |
because we don't have the resources to do so. That is part of why |
112 |
overlays.gentoo.org and gentooexperimental.org exist. If you are |
113 |
proposing that Gentoo try to do these things I would suggest talking |
114 |
to the Infrastructure folks about it. |
115 |
|
116 |
> |
117 |
> To find the mechanism that would allow to maintain functionality of |
118 |
> Gentoo as whole, solve compatibility issues etc. without too much of a |
119 |
> huge organization that needs more and more energy to keep itself |
120 |
> going... writing summaries and attending meetings while there is less |
121 |
> and less time left to do the actual work - that is the problem. |
122 |
> |
123 |
> Thanx for your time reading this. |
124 |
|
125 |
Thanks for writing. |
126 |
|
127 |
-Alec |
128 |
|
129 |
> |
130 |
> Jan Bilek. |
131 |
> -- |
132 |
> gentoo-nfp@l.g.o mailing list |
133 |
> |
134 |
> |
135 |
-- |
136 |
gentoo-nfp@l.g.o mailing list |