From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: What a modern collaboration toolkit looks like Date: Sun, 30 Dec 2007 07:22:17 -0500 (EST) Message-ID: <20071230122217.3CA84830B9A@snark.thyrsus.com> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1199017362 15244 80.91.229.12 (30 Dec 2007 12:22:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Dec 2007 12:22:42 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 30 13:22:55 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J8xBr-0008D2-3n for ged-emacs-devel@m.gmane.org; Sun, 30 Dec 2007 13:22:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8xBV-0000id-ED for ged-emacs-devel@m.gmane.org; Sun, 30 Dec 2007 07:22:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J8xBR-0000iY-BJ for emacs-devel@gnu.org; Sun, 30 Dec 2007 07:22:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J8xBQ-0000iF-MR for emacs-devel@gnu.org; Sun, 30 Dec 2007 07:22:24 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8xBQ-0000iC-Fb for emacs-devel@gnu.org; Sun, 30 Dec 2007 07:22:24 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5] helo=snark.thyrsus.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J8xBQ-00006L-9p for emacs-devel@gnu.org; Sun, 30 Dec 2007 07:22:24 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 23) id 3CA84830B9A; Sun, 30 Dec 2007 07:22:17 -0500 (EST) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:85669 Archived-At: 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 . 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. -- Eric S. Raymond 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