Here we go down the subjective alley ..
Lately, I have been adding a file called ‘whiteboard.txt’ in some of my repositories. I use Mercurial, but this applies to any DVCS.
The purpose of the text file is to hash out formats, flow, ideas, etc. Given that most distributed version control systems have some sort of web interface, why not denote one directory as a ‘wiki’ and allow it to be viewed and used as such using something like Wiki Creole markup?
Obviously, only those with commit access could make changes.
My point is, when the code is ready to release, the design wiki and quite a bit of documentation would be done. Why not integrate the two most important collaborative tools into one?
For instance, if I could:
hg –wiki and find the reasoning behind a group of 30 patches as well as their intended direction beyond abbreviated comments in the commit log .. wow 🙂 Any commit could reference a wiki entry, moreover discussions become part of the repository and not a secondary site.
If you like using a DVCS because you can work off line, why would this not make sense?
EDIT:
The whole point of this would be, if ‘joe’ commits a file, he should be able to set a ‘nag’ attribute which prompts anyone else changing the file to update a certain wiki page, all done while off line with future merges resolved behind the scenes. After all, it is text, not code and can be treated as a FIFO.
If you can commit off line, you can also update a wiki off line and push your changes later, even in patch format.
The idea is deceptively simple.
perhaps http://ikiwiki.info/
A wiki compiler. You can instruct it to store the wiki sources (markdown text files) in a repository (e.g. git, mercurial, subversion). Edits can be done via web, or working copy.