1 |
On 07:48 Fri 10 Jun , Donnie Berkholz wrote: |
2 |
> I served on the council for two terms from 2007-2009. I'd welcome the |
3 |
> opportunity to provide the perspective of someone who has a long history |
4 |
> with Gentoo and a deep understanding of our philosophy and culture (I |
5 |
> joined in 2003 — wow, that's 8 years!). I plan on sending more detail |
6 |
> later, but my interests as a council member include: |
7 |
|
8 |
As promised, here's more info on who I am, why I'm running, how I see |
9 |
the council, and how I see Gentoo. |
10 |
|
11 |
For anyone newer, I'd like to first introduce myself and my history with |
12 |
Gentoo. Over the past 8 years, I've spent time doing pretty much |
13 |
everything in Gentoo, from maintaining ebuilds to writing documentation |
14 |
and leading teams and projects. I've been a recruiter in devrel, served |
15 |
as desktop manager (back when we had top-level project managers, before |
16 |
GLEP 39), and later chaired the council. I also started the clustering |
17 |
team, led X11 maintenance for about 5 years (when I designed the modular |
18 |
X eclass and wrote all 400+ new modular packages as we transitioned from |
19 |
the old XFree86), spent a term as a foundation trustee, and acted as |
20 |
project manager for our ever-controversial GUI installer. |
21 |
|
22 |
One of my primary roles at the moment is running our participation in |
23 |
the Google Summer of Code, one of our major sources of both income and |
24 |
new developers. Since I took over 3 years ago, we've more than doubled |
25 |
the size of our program (we have 15 students this year!) and greatly |
26 |
increased the proportion of students who eventually become Gentoo devs |
27 |
to roughly 67%. |
28 |
|
29 |
At this point, I'm convinced I can make the biggest difference to Gentoo |
30 |
in two ways: focusing on specific projects like the git transition and |
31 |
improved eclass testing rather than ebuild maintenance (which we have |
32 |
tons of people doing), and leading Gentoo to greatness as a council |
33 |
member, where I'm in the best position to accomplish that goal. |
34 |
|
35 |
On my last two terms as a council member, I was extremely active in |
36 |
council-related issues both on mailing lists and at meetings, rather |
37 |
than just showing up at meetings to vote and then disappearing into the |
38 |
sunset. I strongly believe that through preparation and accountability, |
39 |
we can have a more productive council, but this requires a true |
40 |
commitment on the part of every member. |
41 |
|
42 |
> - creating a great community, |
43 |
|
44 |
I see this as an area where the council can set direction for all of |
45 |
Gentoo, both through the positive examples of its members and by taking |
46 |
a stand against anything we won't stand for in our community. The |
47 |
council should be providing guidance to devrel and userrel on what kinds |
48 |
of behaviors should be encouraged and what kinds shouldn't be tolerated. |
49 |
|
50 |
Additionally, we should begin collecting metrics on our community so we |
51 |
know where we're going. Many other projects (and even distributions) do |
52 |
this already, to give them clues of when things are going wrong, what |
53 |
things are going right, etc. |
54 |
|
55 |
> - making progress now instead of waiting years for perfection, |
56 |
|
57 |
There's a lot of ongoing projects and GLEPs that have been dragging on |
58 |
for years because people want a "perfect" solution. One personal example |
59 |
is the git transition, where I've already made this mistake in spending |
60 |
quite a bit of time trying to get a perfect repository layout working |
61 |
when we could have just done a simple conversion of the whole tree and |
62 |
put it in one repo (the current plan, with some changes). |
63 |
|
64 |
GLEP 55 is another one. There are some times when any decision is better |
65 |
than no decision. |
66 |
|
67 |
> - removing bureaucracy in favor of more agile development & meritocracy, |
68 |
|
69 |
We all know that GLEP 39 needs some changes. I think that most devs just |
70 |
want to Get Stuff Done without fighting with policies, waiting around |
71 |
forever for votes, not getting majorities without any clear direction, |
72 |
and so forth. I believe that our devs vote in the council because they |
73 |
want those people in charge and trust the council members to do what |
74 |
they think is right, including deciding on changes to GLEP 39 to improve |
75 |
how we run things. |
76 |
|
77 |
I favor a switch to a smaller group more along the lines of the Linux |
78 |
kernel, with a very small leadership core and more of a hierarchy than a |
79 |
huge committee. |
80 |
|
81 |
Along the same lines, I favor a switch to a more meritocratic approach |
82 |
such as the lead appointments we've been discussing recently. Gentoo |
83 |
isn't a country government that needs to provide for every sick and |
84 |
needy person in its geography; it's a nonprofit with specific goals it |
85 |
needs to accomplish and should be run as such. In general, companies, |
86 |
including nonprofits, don't have checks and balances or long, drawn-out |
87 |
votes. What they do have is a board of trustees at the top, which can |
88 |
replace the leadership when it deems necessary. |
89 |
|
90 |
Another major problem is the lack of continuity in our leadership, |
91 |
mainly because the whole group is re-elected en masse every year. At a |
92 |
minimum, even if we can't do the above changes, we should switch to a |
93 |
2-year term and have half the council up for election each year so new |
94 |
councils can start out quickly. |
95 |
|
96 |
> - promoting innovation from individual developers instead of expecting |
97 |
> it to all come from the top, and |
98 |
|
99 |
As I mentioned above, one of my focuses now is working on interesting |
100 |
standalone projects. I hope that every developer does the same; in |
101 |
addition, or besides whatever you do every day (maintain ebuilds, |
102 |
write/translate docs, etc.), consider starting a new project that has a |
103 |
clear end in sight and that will help Gentoo get better. It doesn't have |
104 |
to be anything big; and the great thing about projects with a finite |
105 |
length is that you actually finish them at some point. |
106 |
|
107 |
> - getting rid of policies that were created for a single incident, |
108 |
> because they should only exist for patterns of repeated problems. |
109 |
|
110 |
I've elaborated on this elsewhere in this thread. |
111 |
|
112 |
-- |
113 |
Thanks, |
114 |
Donnie |
115 |
|
116 |
Donnie Berkholz |
117 |
Sr. Developer, Gentoo Linux |
118 |
Blog: http://dberkholz.com |