Does it make sense to use a wiki for issue tracking instead of using a standalone BTS? Martin Krafft suggested this might be a useful addition to ikiwiki.
It seems to me that this would mostly be worthwhile if it took advantage of the free form, open nature of the wiki in useful ways. Reconciling that with some of the more structured needs of a BTS is an interesting challenge.
Surveying a few examples of using a wiki as a BTS:
- jspwiki tracks issues in a BTS built using the wiki. They have a bug report form with several fields, basic queries for open and closed bugs, and wiki pages for each bug with a table of the fields at the top.
- ikiwiki tracks todo items using a blog. Metadata is currently limited to tagging an item as done. (All I've felt the need for so far; other tags could be used for things like severity, versions, etc.) Each todo item is its own wiki page. You can subscribe to RSS feeds of new or fixed items and use ikiwiki's standard subscription features to subscribe to diffs of changes to particular item(s).
- trac does not seems to actually use a wiki for its bug tracking component
- pmwiki has an issue tracker integrated into the wiki. Fairly similar to jspwiki though seems less refined. Includes a wacky voting system.
- Update: Simon Michael pointed me at Zwiki's tracker, which is at least superficially similar to jspwiki and pmwiki's trackers. One interesting thing is that it supports email submissions.
There is a definite feeling about all of these of finding a vaguely nail-shaped bit and pounding on it with the wiki-hammer, but I'm unsure whether it's really a nail or just an obvious pointy bit sticking up out of the main problem of issue tracking. On the other hand, the same could probably be said about a BTS built using a relational database.