Group projects..

[Michael Maher <mike@redhat.com>]

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. 

http://liw.iki.fi/liw/texts/debian-lessons.html

	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
	going smoothly.

	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
scoile@redhat.com             S o f t w a r e               (919) 547-0012