Gentoo Archives: gentoo-project

From: Donnie Berkholz <dberkholz@g.o>
To: Roy Bamford <neddyseagoon@g.o>
Cc: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Gentoo Council Nominations for 2011 to 2012
Date: Mon, 27 Jun 2011 04:16:50
Message-Id: 20110627041602.GA22047@comet
In Reply to: Re: [gentoo-project] Gentoo Council Nominations for 2011 to 2012 by Donnie Berkholz
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