[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
It seems to me that these ideas can easily be applied to other realms
of activity in developing linux gaming projects. though this isn't game
specific, it might be useful to keep in mind.
This text lists the important things I think the Debian
development community has learned about project management in
the course of developing the Debian GNU/Linux system. These
are my personal opinions, not those of the project or other
developers. I hope this list will be useful to Debian, other
Linux distributions, and other free software projects.
Thanks to the people on Debian's IRC channel for feedback since
the first private drafts.
Make sure things scale up. Problems are always simpler when the
project is small. When the number of developers and packages
grows a lot, small problems become big problems. Make things
distributed so that things can be worked on in parallel.
Make sure the foundation is good. Debian has a pretty good
package management system (even though it has lots of minor
flaws and warts). This makes it much easier to build the system,
when one can concentrate on making packages better, instead of
having to fight the base system.
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.)
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. Debian examples include dinstall (moves
uploaded packages into the ftp server), lintian (checks for many
errors that are easy to make), and the various autocompiling
projects for porting efforts. They're all absolutely necessary
for Debian for maintaining high levels of quality.
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
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.
Make it easy to work independently. The more interdependencies
things have, the more communication is needed (read: less time
spent on productive hacking) and the bigger the chance that a
single developer or package will cause big problems.
Do not overload developers. Developers are volunteers with
too little free time. Make as few requirements on their time
as possible. For example, do not require that they follow
high-volume mailing lists. Overloaded developers have a tendency
to disappear, or at least their packages will be of lower
quality or less up-to-date than they might be. Also do not let
developers overload themselves by trying to do too much, and
make it easy (culturally and technically) to give up packages,
when the workload gets too high.
Be open and keep things in public. If you're popular, your users
will want to know what is going on. Do not decide things behind
closed doors. Allow everyone to read the discussions leading to
decisions and, preferably, allow everyone to participate in them,
even if they aren't developers. Developers may need a private
forum as well, but it should be used as little as possible. By
doing things in private, you are hiding your motives and other
people will be assuming the worst and react accordingly.
Make it easy to contribute. There's never too many developers,
so make it natural and easy for people to join in and help with
what they can, even if it is just reporting bugs. Debian has
recruited several hundred developers this way, and manages to
have thousands of packages. Many developers only have one package,
but it tends to be one they need themselves, so they're motivated
to keep it working.
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. Unfinished fights will easily
haunt the project. Developers do not have to like each other,
but they do have to get along.
Use a bug tracking system. An open bug tracking system makes it
harder for bugs to be forgotten when developers are too busy,
or leave the project, or lose their disks. It also lets people
see whether they want to use a package before installing it,
and to find solutions or workarounds for bugs that are already
known but not yet fixed.
Steve Coile R e d H a t Systems Administration
firstname.lastname@example.org S o f t w a r e (919) 547-0012