Re: [gentoo-project] Gentoo Council Nominations for 2011 to 2012

[Donnie Berkholz <dberkholz@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 6096 bytes --]

On 07:48 Fri 10 Jun     , Donnie Berkholz wrote:
> I served on the council for two terms from 2007-2009. I'd welcome the 
> opportunity to provide the perspective of someone who has a long history 
> with Gentoo and a deep understanding of our philosophy and culture (I 
> joined in 2003 — wow, that's 8 years!). I plan on sending more detail 
> later, but my interests as a council member include:

As promised, here's more info on who I am, why I'm running, how I see 
the council, and how I see Gentoo.

For anyone newer, I'd like to first introduce myself and my history with 
Gentoo. Over the past 8 years, I've spent time doing pretty much 
everything in Gentoo, from maintaining ebuilds to writing documentation 
and leading teams and projects. I've been a recruiter in devrel, served 
as desktop manager (back when we had top-level project managers, before 
GLEP 39), and later chaired the council. I also started the clustering 
team, led X11 maintenance for about 5 years (when I designed the modular 
X eclass and wrote all 400+ new modular packages as we transitioned from 
the old XFree86), spent a term as a foundation trustee, and acted as 
project manager for our ever-controversial GUI installer.

One of my primary roles at the moment is running our participation in 
the Google Summer of Code, one of our major sources of both income and 
new developers. Since I took over 3 years ago, we've more than doubled 
the size of our program (we have 15 students this year!) and greatly 
increased the proportion of students who eventually become Gentoo devs 
to roughly 67%.

At this point, I'm convinced I can make the biggest difference to Gentoo 
in two ways: focusing on specific projects like the git transition and 
improved eclass testing rather than ebuild maintenance (which we have 
tons of people doing), and leading Gentoo to greatness as a council 
member, where I'm in the best position to accomplish that goal.

On my last two terms as a council member, I was extremely active in 
council-related issues both on mailing lists and at meetings, rather 
than just showing up at meetings to vote and then disappearing into the 
sunset. I strongly believe that through preparation and accountability, 
we can have a more productive council, but this requires a true 
commitment on the part of every member.

> - creating a great community,

I see this as an area where the council can set direction for all of 
Gentoo, both through the positive examples of its members and by taking 
a stand against anything we won't stand for in our community. The 
council should be providing guidance to devrel and userrel on what kinds 
of behaviors should be encouraged and what kinds shouldn't be tolerated.

Additionally, we should begin collecting metrics on our community so we 
know where we're going. Many other projects (and even distributions) do 
this already, to give them clues of when things are going wrong, what 
things are going right, etc.

> - making progress now instead of waiting years for perfection,

There's a lot of ongoing projects and GLEPs that have been dragging on 
for years because people want a "perfect" solution. One personal example 
is the git transition, where I've already made this mistake in spending 
quite a bit of time trying to get a perfect repository layout working 
when we could have just done a simple conversion of the whole tree and 
put it in one repo (the current plan, with some changes).

GLEP 55 is another one. There are some times when any decision is better 
than no decision.

> - removing bureaucracy in favor of more agile development & meritocracy,

We all know that GLEP 39 needs some changes. I think that most devs just 
want to Get Stuff Done without fighting with policies, waiting around 
forever for votes, not getting majorities without any clear direction, 
and so forth. I believe that our devs vote in the council because they 
want those people in charge and trust the council members to do what 
they think is right, including deciding on changes to GLEP 39 to improve 
how we run things.

I favor a switch to a smaller group more along the lines of the Linux 
kernel, with a very small leadership core and more of a hierarchy than a 
huge committee.

Along the same lines, I favor a switch to a more meritocratic approach 
such as the lead appointments we've been discussing recently. Gentoo 
isn't a country government that needs to provide for every sick and 
needy person in its geography; it's a nonprofit with specific goals it 
needs to accomplish and should be run as such. In general, companies, 
including nonprofits, don't have checks and balances or long, drawn-out 
votes. What they do have is a board of trustees at the top, which can 
replace the leadership when it deems necessary.

Another major problem is the lack of continuity in our leadership, 
mainly because the whole group is re-elected en masse every year. At a 
minimum, even if we can't do the above changes, we should switch to a 
2-year term and have half the council up for election each year so new 
councils can start out quickly.

> - promoting innovation from individual developers instead of expecting
>   it to all come from the top, and

As I mentioned above, one of my focuses now is working on interesting 
standalone projects. I hope that every developer does the same; in 
addition, or besides whatever you do every day (maintain ebuilds, 
write/translate docs, etc.), consider starting a new project that has a 
clear end in sight and that will help Gentoo get better. It doesn't have 
to be anything big; and the great thing about projects with a finite 
length is that you actually finish them at some point.

> - getting rid of policies that were created for a single incident, 
>   because they should only exist for patterns of repeated problems.

I've elaborated on this elsewhere in this thread.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]