is perhaps the biggest thing missing when compared to a plain wiki page.
Integration with the revision control system a la [scmbug](http://www.mkgnu.net/?q=scmbug)
would really neat though, so that bug tracker commands like (closes: #nnn) could
-be embedded to the source code repository commit messages.
\ No newline at end of file
+be embedded to the source code repository commit messages.
+
+> A while back I posted some thoughts in my blog about
+> [using a wiki for issue tracking](http://kitenet.net/~joey/blog/entry/using_a_wiki_for_issue_tracking.html).
+> Google's BTS also has some interesting developments along the lines of
+> free-form search-based bug tracking, a style that seems a better fit to
+> wikis than the traditional rigid data of a BTS.
+>
+> I sorta take your point about bug numbers. It can be a pain to refer to
+> 'using_a_wiki_for_issue_tracking' as a bug name in a place like a
+> changelog.
+>
+> OTOH, I don't see a need for specially formatted commit messages to be
+> used to close bugs. Instead, if your BTS is kept in an ikiwiki wiki in
+> an RCS along with your project, you can do like I do here, and just edit a
+> bug's page, tag it `done`, and commit that along with the bug fix.
+>
+> --[[Joey]]
+
+>> I think a little bit more structure than in a normal wiki would be
+>> good to have for bug tracking. Bug numbers, automatic timestamps on comments
+>> and maybe an email interface would be nice. The resulting page may not
+>> look like a wikipage anymore, but rather something like the Debian
+>> BTS web-interface, but it would still benefit from wikilinks to the
+>> documentation in the wiki etc.
+>>
+>> About the commit message interface: I was thinking about a project
+>> architecture where the code is kept in a separate revision control
+>> system branch than the metadata (blog, wiki, BTS). This would IMHO
+>> be a cleaner solution for distributing the source and making releases
+>> etc. For this kind of setup, having the BTS scan the messages of the
+>> source branch (by a commit-hook for example) would be useful.
+>>
+>> By Google BTS, do you mean the issue tracker in the Google code
+>> project hosting?
+>>
+>> --Teemu
+
+[[wishlist]]