"Lessons from the Debian Project"

[Seth Nickell <snickell stanford edu>]

I stumbled upon this randomly while hacking on ApplicationManager. Its
pretty simple, but the lessons are, I think, profound. The document can
be found at http://liw.iki.fi/liw/texts/debian-lessons.html.

Here's a selection of "lessons" I think the GNOME project is facing
today...

> Document important things. When people need to work together, they
> need to know how to take each other in consideration. There needs 
> to be rules about how packages are laid out so that they don't
> interfere with each other. If these rules aren't written down, they 
> need to be remembered by the community memory and word of mouth, both
> of which are unreliable. The Debian Policy documents are a fine 
> example of this. Debian couldn't live without it.

> (Note that when documenting things it's important to document the 
> reasons behind the decisions as well. Debian Policy documents don't
> do this well enough, though, at the moment.)

We've started forming policy, for example with Federico's account
policy, or the RFP process. Could we store all this sort of policy in a
single location? Sort of a "HOWTO" do X within the GNOME project ;-)

> Automate repetitive tasks when possible. Repetitive tasks should
> be automated, especially if they are tricky or critical. This reduces
> the number of human errors, and also frees up developers to more 
> important tasks.

I don't know to what extent this has been done. For example, how
difficult is it to create CVS accounts right now (and if its
easy...which does it usually take so long to do?).

> Avoid single points of failure, especially for volunteers. Volunteers
> will always lack time at the critical point. For critical jobs, have
> several people share the workload and make sure there are mechanisms
> for checking that things are going smoothly.

I think this has been done pretty well, except with respect to system
admin tasks, account approval and the like. Particularly pertaining to
system administration, I have talked with a few competent system
administrators online (who manage large systems in their "real world
jobs") who are interested in helping the GNOME project but were
frustrated with people's disinterest in sharing responsibility.

For example, who can alter the DNS for x.gnome.org, who can fix CVS
machines when they go down, or even simply do moves of CVS
directories...

> Do not worry about time tables; keep goals realistic. In big
> volunteer projects, time tables will always slip. That is not
> a catastrophy, and it must be tolerated, but there should still 
> be some effort in keeping them. Goals must be kept realistic.

> Have leadership. There must be some way to solve conflicts and 
> arguments, if a natural consensus doesn't occur. Different 
> projects may need different kinds of leadership, but there has 
> to be some way, formal or informal.

> Conflicts are natural, but mustn't get out of hand. Developers
> are often opinionated, strong-minded, and bullheaded. You can't
> avoid that. They must be allowed to scream at each other every
> now and then, but fights must not be allowed to escalate. 
> Everyone in the project will have to be responsible for
> mediating between disagreeing parties, if they can't come to a
> consensus by themselves. 

We need to deal with conflicts better. It seems like our current policy
is "fights will go on as long as they have to". People get tired of
fighting and stop, but the issue is not solved, the problems flair up
again after people have taken a recess from fighting.

**********
> Unfinished fights will easily haunt the project.
**********

indeed.

-Seth



_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers