Trac is nice too, it has a built-in wiki with it’s issue tracker and svn browser. Yeah, I have to say, of all these, Mediawiki is my favorite. Never tried the perl-based ones, though.

Wiki for maintaining specifications sounds cool to me; though would be bit difficult for customers who have not worked with wikis -
1. Mostly people prefer to read hardcopies and collaborate through emails
2. Taking printouts would be require another how-to
By the it seems your working on plenty of wikis aren’t you ? Which wiki you prefer?

Actually, I had the same doubts after I read about 37signals’ stance. I agree with Joel on maintaining proper schedule – and his scheduling method is pretty agile – incorporating slippage of dates, which happens all the time. But I’m not so sure about the specs. I wouldn’t say we don’t need specs at all, because having some kind of scope & specification documents is important in dealing with customers.

Maybe not as detailed as Joel posits. I certainly won’t go to the pain of creating paper prototypes except in the initial stage, to give a feel of the website to the customer. Because, as we all know, such nicely-prepared specs inevitably grow obsolete in a few months. I think this is where wikis are a major help – you note down your specs, get the customer to agree, and start working. Any changes, you ask the customer to add to the wiki or you do it yourself.

The advantage is that, our specs are not obsolete as soon as we get the first release out, and we have the history of what changes are made so far (all decent wikis support versioning). We can use this as the evidence when inevitable disagreements with the customer show up. More transparency, more agility. Both the service provider and the customer win. What do you say?