ikiwiki (3.20130711) unstable; urgency=low
[ikiwiki.git] / doc / todo / Better_bug_tracking_support.mdwn
1 I see that ikiwiki has already some [[bugs]] stored on the wiki, but adding
2 better support for bug tracking would really make it a good project
3 management system for small projects. Storing the sourcecode, wiki, developer
4 blog and the issue tracker information under a same revision control
5 system really makes sense. At the moment the only part missing from ikiwiki 
6 is the bug tracker plugin.
7
8 The support would not need to be anything fancy, assignment of bug numbers
9 is perhaps the biggest thing missing when compared to a plain wiki page.
10 Integration with the revision control system a la [scmbug](http://www.mkgnu.net/?q=scmbug) 
11 would really neat though, so that bug tracker commands like (closes: #nnn) could 
12 be embedded to the source code repository commit messages.
13
14 > A while back I posted some thoughts in my blog about 
15 > [using a wiki for issue tracking](http://kitenet.net/~joey/blog/entry/using_a_wiki_for_issue_tracking.html).
16 > Google's BTS also has some interesting developments along the lines of
17 > free-form search-based bug tracking, a style that seems a better fit to
18 > wikis than the traditional rigid data of a BTS.
19 >
20 > I sorta take your point about bug numbers. It can be a pain to refer to
21 > 'using_a_wiki_for_issue_tracking' as a bug name in a place like a
22 > changelog.
23
24 >> Would a modified [[plugins/inline]] plugin that allowed new pages, but without a title field, be ok?
25 >> When you hit the edit button it just chooses a new number and makes a page with that
26 >> name.
27
28 >> The only issue I can see with this is if you're using a distributed wiki for
29 >> distributed bug tracking.  In that case you're going to have to make sure that you
30 >> don't get conflicting bug ids.
31 >> Maybe there should be two options - consecutive numbering, and uuid numbering
32 >> which uses a random (128 bit, base64 encoded = 22 chars) name. -- [[Will]]
33
34 > OTOH, I don't see a need for specially formatted commit messages to be
35 > used to close bugs. Instead, if your BTS is kept in an ikiwiki wiki in
36 > an RCS along with your project, you can do like I do here, and just edit a
37 > bug's page, tag it `done`, and commit that along with the bug fix.
38 >
39 > --[[Joey]]
40
41 >> I think a little bit more structure than in a normal wiki would be
42 >> good to have for bug tracking. Bug numbers, automatic timestamps on comments
43 >> and maybe an email interface would be nice. The resulting page may not 
44 >> look like a wikipage anymore, but rather something like the Debian 
45 >> BTS web-interface, but it would still benefit from wikilinks to the 
46 >> documentation in the wiki etc.
47
48 >>> I think it is useful to look at these things separately:
49 >>>
50 >>> * Bug numbers: See above.
51 >>> * Automatic timestamps on comments: this already exists with the inline directive.
52 >>> * Email interface: You can certainly get an rss feed of what changes in the wiki.
53 >>> * You didn't mention [[todo/structured_page_data]] but that is, I think, part
54 >>>     of what you seem to be saying.
55 >>> * [[todo/tracking_bugs_with_dependencies]] is also important.
56 >>>
57 >>> -- [[Will]]
58
59 >> About the commit message interface: I was thinking about a project
60 >> architecture where the code is kept in a separate revision control
61 >> system branch than the metadata (blog, wiki, BTS). This would IMHO
62 >> be a cleaner solution for distributing the source and making releases
63 >> etc. For this kind of setup, having the BTS scan the messages of the 
64 >> source branch (by a commit-hook for example) would be useful.
65 >>
66 >> By Google BTS, do you mean the issue tracker in the Google code 
67 >> project hosting?
68 >>
69 >> --Teemu
70
71 [[wishlist]]