It’s been a while, but Joey Hess replied publicly to a discussion we had on IRC, but he only looked at whether issue tracking in a wiki makes sense. Thus I wanted to add my point of view. Three months after I originally started this post. Oh well.
The reason I contacted Joey Hess was because I was (and am still) on the look for better tools for my personal information management, and I identified several important aspects I’d want from such a system:
- An issue tracker, to be used as my own todo list
- A wiki, or some form of integrating web frontend to make it easy to browse the information and give others granular access to it.
- A backend store that can be properly synchronised across several machines (so that I can always have an offline copy on my laptop).
- A command-line interface for manipulation of existing and addition of new contents. I want to use the regular Unix tools for the interaction.
- A blog engine.
- Granular permissions, either based on a Netware-style user database with records of content-and-permission tuples per user, or a simple password protection for individual content items.
- A mail-in interface for new issues, so that I can simply bounce mails by customers to the system and have it assign a ticket number. Given a command-line interface, though, this could be added without much effort.
In terms of integration, I am thinking mostly about WikiWords that get automatically linked to the corresponding wiki pages, if these exist, and across all components; so if I write a blog entry or add a new issue to the tracker, I can easily refer to content on my own wiki (or the issue tracker, or blog) without much typing. I imagine further synergies are possible but have not put much time into thinking about those.
The main reason I contacted Joey about this, because his ikiwiki has a backend store capable of synchronisation: it’s a wiki engine (which can also be used for blogging), but it’s based on the subversion version control system. Together with svk or bzrsvn, it definitely meets the synchronisation requirements about as good as it gets.
But ikiwiki falls short in three main points for
me:
- it does not integrate an issue tracker, so I’d have to use another product and hack up the integration.
- it is based on Subversion, but it does not include a browser for the version control system. Joey may argue — and I would have to agree with him on principle — that such a component has no place in Ikiwiki and there are already plenty of other tools that do a better job at repository browsing than he’d ever be willing to implement. But still, I’d like to have integration with the version control system and be able to easily refer to files and changesets, again without jumping through hoops.
- it is written in Perl and I am not much of a Perl hacker, so it’s not going to be easy for me to contribute to and extend the code base.
Also, ikiwiki does not have a permissions
subsystem, though I’m sure it would be possible to add that fairly
easily.
Many who have read this far will probably think Trac, which I’ve also inspected.
Trac is written in Python (which I grok), and it
integrates a wiki engine with an issue tracker and a (single)
repository browser much in the way I want it.
However, it comes without granular permissions, and wiki content and issues are stored in an SQL backend, rather than the version control repository to which a Trac instance can be bound. This also leaves it without a command-line interface or synchronisation abilities — unless I want to manipulate SQL records and set up replication between SQL backends. If you care, I am not the only one who wants to see Trac use the VCS backend for wiki content and issue storage.
So I am still on the look. If you have any comments, please mail me.
NP: Sybarite / Placement Issues
Update: Joey tells me that ikiwiki now also
supports git, Mercurial, and tla
backends, and that Monotone is in preparation. I wonder how long
it’ll take until bzr is added.
Update: He also responded to my post.
