At our company we use TWiki not only for creating a knowledgebase and discussion forums, but also for tracking time spent on specific tasks and documenting exactly what we've done.
For instance, installing a new server, installing packages and patches, debugging all sorts of odd problems, etc. All these tasks take time and we wanted to know how much time we spend on them. The added benefit is being capable to show the boss we work a hell of a lot, contrary to what bosses usually think of sysadmins :).
Here's how it works: we created a special kind of topic we called a TicketWiki
. Its name follows the convention TickeTYYYYMMMDDX
, like TickeT2001May06A
, B, C, and so on. We made a separate edit script that automatically creates the next vacant name, so you don't have to do it by yourself.
A ticket is nothing but a topic with a special category table listing who did the request, at what time, the people involved in the execution, the date and time when these people started and finished working on the problem and a status:
- TicketPending: someone requested but no one took it yet
- TicketInProgress: someone is taking care of the problem/request
- TicketFinished: task sucessfully finished
- TicketToBeContinued: some work was done but we ended our "work session" on the task without actually finishing it.
- TicketCancelled: marks dropped tasks, inappropriate requests, etc.
The request itself and its detailed solution are kept in the text of the topic.
We wrote special versions of the SEARCH inline variable that filters the topics by values within its category table, so its easy to write topics that search pending tickets, all tickets for the current wikiuser and such. We also wrote a variation that computes elapsed time for every ticket, multiply by the amount of people involved in each of them and reports man-hours spent on each task and by user by month.
Albeit simple, this model has been working quite fine for us. Its has proven to be quite simple to implement and the results are encouraging. In it is everyday use, however, we found it surprisingly nontrivial in its implications and ramifications. Newbies take certain time to understand the model, but they benefit a lot from being able to quickly get acquainted with what is going on when joining new projects. It's been great to be able to pinpoint exacly who did what and when, reuse others people's (and sometime our own's that we forgot) solution to certain problems.
These things needed some patching direclty on wiki.pm and a few new scripts. If anyone is interested, we can post the patches and extend this discussion -- there's a lot I omitted for sake of brevity. I don't think this feature would be appropriate for vanilla TWiki, but it might just become a nice plugin -- we look forward to reimplement this using the TWikiPluginAPI
- 06 May 2001
I for one would love to hear more about this!
- 07 May 2001
With most ticketing systems I know, you simply count them.
A date scheme adds complexity to a name without helping much.
could be an alternative,
but you might run out of names if you receive many duplicate calls,
requests... So I did something very simple:
read value < $counter # race condition here!!!
value=`expr $value + 1` # we rely on twiki locking
echo $value > $counter # to resolve a clash
# -- fixed stupid typo, Main.PeterKlausner 9.5.01
echo "Location: $url/$value
" # output the HTTP redirect statement
Then open an Issue with this form code:
<input type=submit value="Create New Issue">
for this web fills the issue skeleton
and of course you want a few categories like:
Linking means typing
not more complicated than the above scheme.
I picked up the wording "Issue" from the Issuezilla
project [ http://www.openoffice.org/bugs/issues.html
which is a more generalized Bugzilla
- 08 May 2001
That is a nice system you describe!
It would be nice to make this available as a plugin. We probably need to extend the plugin API, for example with a topic save hook, so that it is possible to do some more advanced stuff like notifying the assigned person by e-mail when the status changes.
- 11 May 2001
It looks like Sandbox.ChangeRequest
together with the ActionTrackerPlugin
could happily fulfil this.
- 17 May 2003
actually, you can see an implementation of this at http://develop.twiki.org/~develop/cgi-bin/view/Bugs/WebHome
- we're going to use it to track bugs in DevelopBranch
- 07 May 2005
I've haven't been tracking TWiki.org topic changes or the irc logs very closely the past two months. Has this new bug tracking system been discussed anywhere?
Should we still be using BugReport
, if so for what? or should the submission form be removed and replaced with a link to the new Bugs web?
- 07 May 2005
a small mention of it in irc, but otherwise, i'm keeping it a little quiet until a few core people play with it a bit..
its only for tracking issues in the non-released DevelopBranch
, so no, don't remove the existing systems
- 07 May 2005