1 |
On Thu, 2008-01-31 at 13:50 -0700, Daniel Robbins wrote: |
2 |
> |
3 |
> Also, your point about managing a volunteer group that is this large |
4 |
> is well taken. My current approach to solve this problem is avoid the |
5 |
> issue in the first place and work with smaller volunteer groups. I |
6 |
> think this "solution" is something that the future heads of Gentoo |
7 |
> should consider. With the software development tools that exist today, |
8 |
> much of this centralization can be avoided in the first place. |
9 |
|
10 |
But I think to some degree that is already taking place. For example, |
11 |
take the Java Team and Project. We pretty much operate and live in our |
12 |
own little world. And get involved with other aspects outside of our |
13 |
sphere when need be. |
14 |
|
15 |
I just think there might be gaps in the over all hierarchy with all the |
16 |
smaller groups/teams/projects. It's fine to have lots of smaller |
17 |
manageable pieces. But how they all fit back into the larger integrated |
18 |
unit as a whole. Is much more complicated. |
19 |
|
20 |
The middle is where the biggest problems seem to lie. Between the teams, |
21 |
leads, and the council. As much as it's a horrible title, but middle |
22 |
management might play a role there. To benefit both ends, council and |
23 |
the projects. Coordinator might be a better title than middle |
24 |
management. |
25 |
|
26 |
Those things seem to exist for like release management. But likely other |
27 |
areas where "coordinators" or "middle managers" could play a role. But |
28 |
some of that borderlines on technical operations. So would fall under |
29 |
the realm of the council. |
30 |
|
31 |
I think the council would be open to suggestions there from the board of |
32 |
trustees. But of course do not have to accept anything, or enact |
33 |
anything that the board requests. |
34 |
|
35 |
-- |
36 |
William L. Thomson Jr. |
37 |
Gentoo/amd64/Java |