What a modern collaboration toolkit looks like

["Eric S. Raymond" <esr@snark.thyrsus.com>]

This started out as part of a longer essay called "On not kissing the pig".
But that essay grew into an epic.  Rather than dump it on the list all 
at once, I think it will be useful if I start by giving everybody a
clear idea of the potential benefits of changing our practices.

I'm going to describe the collaboration toolkit on another project where
I happen to be a senior dev, called Battle For Wesnoth.  You can find
the project at <http://www.wesnoth.org/>.

This is a typical modern open-source project.  It's not even a
particularly large one -- no more than a dozen core devs, 58
developers total.  Here are the collaborative tools we use every day:

* Source control with Subversion
* A bug tracker
* A very active IRC channel used for routine dev chatter
* A dev mailing list, used mostly for white papers and long proposals
* Web forums where a large user community hangs out
* Subversion commits are echoed to IRC in real time by a monitor bot
* Subversion commits that reference a bug append a comment to the tracker
* A bot on IRC that you can query with a bug number and get a tracker URL.

Here are some of the ways my workflow on Wesnoth differs from my
workflow on Emacs:

1. When I do a commit of changes to several files, the entire changeset
is saved as a unit with a single change comment attached to it.  

a) That change can be referenced, through its Subversion revision ID.  
   (So, for example, "Hey boucman, your r22615 broke linger mode!")

b) That change can be backed out as a unit.

c) That change is instantly browseable by any dev.

d) If that change is a fix that references a bug number, that fact
   instantly becomes part of the bug database *where everyone can
   see it*.

2. My commit is also echoed to the IRC channel, where there are almost
never fewer than three or four devs hanging out as they hack, chatting
in real time.  Review tends to happen instantly.

3. Because everybody (and our user community!) uses the bug tracker, 
everybody always knows exactly what the dozen most important 
bugs are, and has a pretty good idea what the dozen most valuable
feature requests are.

4. Because the IRC has a monitor bot hooked to the bug database,
whenever someone says "Eric, have you looked at feature request #2355,
it looks like your kind of thing." I can get to that issue by typing
"wesbot: bug #2355" and clicking once.  Questioner usually gets a
response less than 30 seconds later.  If I address the request,
they'll see my commit comment in real time without me having to do
anything special.

5. The entire commit history of the project is visible to me 
moments after I type C-X v l.  This is much more powerful 
than just having the per-file change history visible, because 
the commit groupings themselves tell me valuable things 
about developer intentions.

The effect of all these tools is more than the sum of its parts.
  
One huge one is simply that devs can choose to spend time picking
bugs off the tracker and nailing them, with basically zero process
friction.

Another is that we routinely hash out serious design and coding issues
in real time, because everyone on the chat channel can share hyperlinks
to the codebase, the commit history, the bug tracker, and posts
on the user forums.

Yet a third is that when we decide to do it, we can converge on a
releasable state with almost absurd ease.  Like, Ivanovic (our release
manager) will announce "Point release scheduled this coming Wednesday"
and everyone will pretty much flip into bug-stomping mode.  The
tracker bug list tends to shrink dramatically when this happens --
not only do we get prepared for release but *we know we've done so*.

More generally, development happens *fast*.  I don't have to wait
weeks to find out whether other devs think of an idea.  Commonly
I know within minutes.

The Wesnoth devs are good but not exceptionally so, and we're weighed
down by a crappy implementation language (C++).  Nevertheless our
productivity, in terms of goals achieved per hour of work, is quite
high.  That's because our collaboration tools support everything we do
without imposing noticeable process friction.  This makes us
dramatically more effective as individuals and as a group than we
could possibly be without them.

Lessons for the Emacs project?  Hell, yes.  But I'm not going to 
write that rant until y'all have had a little time to absorb 
this description of how things can be.

And bear in mind: At the end of 2007 this is obervably *normal*.  It's
not that Battle For Wesnoth's collaboration toolkit is ahead of the
curve -- it's that Emacs's is behind.  Way, *way* behind.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Americans have the will to resist because you have weapons. 
If you don't have a gun, freedom of speech has no power.
         -- Yoshimi Ishikawa, Japanese author, in the LA Times 15 Oct 1992