Tags:
create new tag
view all tags

Question

How do I build an issue tracking system in TWiki?

Reopening an old issue (HowToBuildBugsTrackingSys) that I think needs a better answer: How does one go about building a Bug or Issue Tracking System using TWiki?

I am being somewhat facetious or tongue in cheek when I ask this: I know how to do it. I know how to set up forms, queries, etc.

But, it sure would be nice if TWiki came with some protototype web that could be used as a template for an issue tracking system. And/or with some tar.gz files that contained consistent examples of an issue tracking web.

... ok, TWiki does come with such a system - e.g. Plugins.BugsContrib. But for various reasons (not least of which is that I am not doing bug tracking, but issue tracking), I may not want to use Plugins.BugsContrib. How do I go about rolling my own issue tracking system?

  • I suppose that I am morphing this support request into a mini-tutorial on how to do this...
  • ... I'll create a new support item (inviting others to add).

Environment

TWiki version: TWikiRelease01Feb2003
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS:  
Web server:  
Perl version:  
Client OS:  
Web Browser:  

-- ChrisWong - 19 Oct 2003

Answer

Randy Kramer's Response: Issue Tracker = Standardized Data + Search

Sorry, I won't give you the detailed step by step, I think there is actually a page that does that but I haven't tried searching for it (I may be thinking of a set of instructions for something more like a todo list).

  • AndyGlew: I'm looking for that master page. Haven't found it yet. But then, I've only been searching 4 hours. frown

Anyway, this is not that hard (I know, that's easy for me to say), but you may have to learn some new terms or concepts.

Basically, there are two steps involved:

  1. On each page that you want to include in the Bug Tracking List, you need to include one (or more, if you want to get tricky) terms that you want to classify the pages by. For example, the Bug Tracking list uses terms like: (I'll get back to this in a minute).
    • BugAssigned
    • BugReports
    • BugResolved
    • BugDuplicate
    • BugRejected

  1. Then, on a page named (for example), BugAssigned, you create a formatted (structured? I forget the preferred TWiki terminology) search that looks for all pages containing the term "BugAssigned" and displays (selected) key data about each of those pages according to the format you specify. Go to BugAssigned and view the page in raw format (or edit it) to see the search "command" used.

Back to putting the term on each page you want listed. You can do this in any way you want. You might just include the term anywhere on the page (you then have to take pains that pages like this, which include the term but aren't really what you are looking for, are not included in your search results), you could hide the term within HTML comments on the page, like <!--BugAssigned--> so the classification term is not visible.

But, the best and most common way is create a TWiki form to be included (automatically) on each page (in one or more webs). On that, you create a "formfield" (IIRC the terminology — it used to be "category", I'd call it a (data) field) of the type that creates a drop down box (you should find this when you find the documentation on creating TWikiForms (on the TWiki web)), and include the five (or more) possibilities (BugAssigned, BugReports, ...).

If you do that, then when somebody creates or edits a page containing a bug, they will be able to choose one of the possibilities by selecting it on the displayed TWiki form, and your search command on the appropriate page will be able to find that page and include it on the list.

Hope this gets you started! If you have specific followup questions, ask them here (or on a more appropriate existing page), and somebody will answer.

PS: Look at this page — see the table labeled WebForm at the bottom? That's the type of TWiki form I'm talking about. Try editing this page and look at the similar table displayed then — click on the down arrow next to SupportStatus and note how you can select alternate statii — that's the kind of TWikiForm you want to create for your pages.

PPS: As you find other resources useful in this effort, how about adding links on this page (and whatever else you find out), to help the next newbie attempting this.

-- RandyKramer - 20 Oct 2003

Thanks for the reply. I've got it now. By the way, how to use a html form instead of "Edit" button to reply message? Thanks a lot.

-- ChrisWong - 22 Oct 2003

You're welcome!

Sorry, I don't think I understand your follow up question, and I'm pretty sure I don't know the answer — maybe somebody else? Hmm, or maybe your looking for (IIRC) the comment plugin? Try looking for that in the plugins web, it lets anybody comment on a page without editing the page.

-- RandyKramer - 22 Oct 2003

When I post a new message to a tracking system, I can use the following html form to do it:

Summary:
Detailed Description:

But how can i use this method to post a follow up message?

Thanks.

-- ChrisWong - 23 Oct 2003

AndyGlew elaborating:

As Randy says above, you basically arrange to put search terms in a page, and then search for them.

Naming Issues

A first step: decide how you want your pages to be named. Common choices:

  • a WikiWord chosen by the user
    • PRO: meaningful to at least that user
    • CON: frequently mischosen.
      • Industry quality bug reporting systems as are used for large software projects have often learned this lesson
      • often needs to be renamed, leading to dangling references
    • CON: quite likely to collide with other bug reports, e.g. "Compiler Bug"
  • to cope with these problems, most bug reporting systems provide some sort of unique ID to issue reports.
    • Autoincrementing sequence number
      • e.g. Item0, Item34, Item2012
      • PRO: easy. See TWiki's XXXXXXXXXX (10X) feature
      • CON: numeric fields may not sort. May need names padded out with leadng zeroes, which does not scale.
    • Date, e.g. YYYY-MM-DD-hh-mm-ss
      • e.g. Item2006-10-04
      • CON: long
      • PRO: provides some instantly visible information
      • CON: may still collide - i.e. may need a sequence number anyway.
    • Overall problems with such unique numbers
      • Tells you approximately where a report was filed. But no instantly visible information.
      • Anyone who has read status reports full of "Fixed Bug76767; filed Eco545" knows how information-free such identifiers ae.
      • You really want "Fixed Bug76767 (assert bug); filed Eco545 (wiring delay in adder)"
      • Not all of this needs to fit in a name.

TWiki can do all of the above.

So far as I can tell, TWiki cannot easily do names of the form [[Item2006-10-04-uid566-SomeSimpleDescription]].

Data Representation

There seem to be two main approaches in TWiki based bug reporting systems:

  1. Put all of the information in forms; disallow using the TWiki freetext
  2. Put information in TWiki freetext
  3. Some hybrid

Forms are more searchable.

Freetext handles the case where the form doesn't anticipate what the user needs.

Creating

Once you have decided on your naming convention, you need to create a system to create a report.

Most TWiki issue tracking systems have a button that creates a new report.

This is typically a form that collects some info, and then creates a page. Or else it is a button that creates a new page, and dumps you in a mode where you can edit the form info and/or the freetext.

I.e. It may create the page immediately, or it may put you in edit mode on a half created page.

In any case, forms info is saved, and/or freetext info is populated from the creation form (URLPARAM) using a template for the newly created page. The template populates the freetext with stuff from the form.

Myself, I find this confusing: a first form creates a page which contains a second form...

Searching

... TBD

WorkFlow

Industrial quality bug tracking systems handle WorkFlow:

  • e.g. when a report is created, it may go to a first level screener.
    • The screener may reject it as not a bug,
    • and/or merge it as substantially the same as an existing bug.
  • it gets routed to a person or group who may be able to fix it
  • when fixed, the change is scheduled
  • if the fix is onerous, it may be necessary to get upper management approval
  • if the fix affects area X, the expert for X should be notified
  • alarms go off if the issue sits unresolved too long.

I am not aware of such workflow in TWiki.

Fortunately, I don't need such workflow for a small, personal, project.

Examples


I think this has been more than adequately answered, so I'm closing it.

-- CrawfordCurrie - 16 Dec 2006

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2016-11-26 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.