I first met Trac several years ago at my previous gig for a cloud project we were developing at that point. Prior to that, we used some in-house support tool developed in Lotus Notes. Prior to that, I used Notepad. And let me tell you, everything you use for issue tracking is fine, as long as you write it down. In these days, Trac seems a bit archaic. After all, there is Jira, there is FogBugz, there is Redmine, there is TFS, to name a few. But the issue here is not in what you use, the problem is how to use it. Issue tracking and project management systems are only as good as users using them. This simply means that the best tool in the world won’t help you, if your users do not know how to use it.

 

You are misusing issue tracking system if…

  1. You only created one ticket (ticket in Trac is what most other systems call issue) for entire project.
  2. You do not use milestones, versions, components etc.
  3. Your milestones and tickets don’t have due date set.
  4. All your tickets have priority set to default or highest possible level.
  5. You move ticket from status “NEW” to “DONE” without accepting it first.

 

How to do it right (sort of)

First, let me say that there are multiple ways to skin a cat. Whatever works for you is fine. This solution only presents observations I encountered during my time as developer/project manager.

 

Create tickets for every task in a project

Lazy project managers try to convince you, that you are only wasting time, but knowing what you need to do before you start coding is a must. Before you start any project, assemble your team (if you are alone, just assemble yourself) and think hard and deep about it and try to split it into tasks that take no more than 8 to 16 hours to implement. Why? Firstly, if a task takes more than 2 working days, it can be split into smaller pieces. Secondly, the error margin is low in short time intervals, so you get better feeling of when you are actually going to ship (in the end, that is all that matters). Also it gives you a sense of accomplishment when you already see what has already been done.

The added on bonus of smaller tasks are shorter commits, which means less issues with merging and more restore points.

 

Use milestones, versions and components

Milestones are basically groupings of tickets that need to be done for that milestone to be completed. Some people use milestones for defining agile sprints, and that is fine. I use it to define a version. Basically, version 1.0 will be done when these tickets are done. Not defining a milestone means that that specific ticket will probably be ignored until someone comes rushing to your desk asking why the issue hasn’t been fixed or the feature implemented. I usually assign all tickets that have no milestone specified and have not yet been discussed, to a Waiting list milestone. This means that we will look at it at our next meeting and decide what to do with it. Tickets get deleted and moved from and to waiting list throughout projects life-cycle.

Versions should only be used for bug reporting purposes. When a bug is reported, a person reporting it should be able to select which version of your software is behaving oddly. This vastly helps locating buggy code.

Components are simply defined as parts of your project. For instance, for CTI project I wrote, I had two components. First was CTI Windows client. Second was called Data server, which was responsible for obtaining data about callers and whatnot. In Trac, you also get a bonus feature of actually seeing how each components progresses, based on tickets completed.

 

Set due date to milestones and tickets

Milestones and tickets are meaningless without due date. Not setting a due date is actually saying: “I’ll be done when I am done”, and that is not how business works. For each task defined by ticket, developer assigned knows pretty well how long it will take, so they should assign a due date, when they start working on that task. Ideally, this dates should be set based on when developer accepted the ticket and what was initial estimate, but I doubt many systems support this kind of automation. Trac doesn’t, so it is up to developer to fill it and project manager to keep an eye on it.

Milestones due dates should be set based on realistic schedules. But we all know what it is like in real world, so they usually represent a compromise between schedule and desired release date. Due dates can change, but moving shipping date is costing your company money and makes you and your team look a bit slow, to put it mildly. Personally, I suggest removing nice-to-have features before actually altering ship date.

 

Set priority level to all tickets

Not all features, tasks and bugs have equal importance. A bug that crashes a system, for instance, should be fixed ASAP, while a bug that occurs every leap year on pink computers when they have 60W light bulb in the office, can wait. Don’t get me wrong, I am all for “fix all bugs prior adding features” concept, but I refuse to spend numerous hours or days, debugging something that will probably never get spotted on account of shipping my project. Again, a feature that will stun the world will get a highest priority, while a painting OK button pink will get lowest. This is why, your tickets have priority fields. And no, they should never be set by a person reporting a bug, because they will instantly get highest priority.

The worst thing I have seen thus far was that all tickets had priority set to default value. This led to developers doing whatever feature they felt like doing first. And trust me, most of those features done were nice-to-have ones.

 

Set ticket workflow and follow it

Another thing that makes my bubble burst are tickets that go from status “New” to “Done” in an instant and without a comment. Don’t get me wrong, some tickets in Waiting list will get closed directly, but at least keep some discipline and write a comment as to why the ticket is not getting attention. Other than that, there is no way a ticket should go from “New” to “Done”. It cannot be done, if it wasn’t accepted first. Not accepting tickets usually smells of a smart developer that tries to cheat the system by commiting code first and filling out the ticket later in hope of manager not finding out what he/she was doing. Not wanting to sound like a jackass, but that usually leads to “interesting” bugs in your project and makes entire development process non transparent.

At one of my gigs, one of my co-workers got assigned with about 5 tickets. Tickets remained in status “New” for about a month. Then, he commited the code, and rushed over to Trac, pasted “This is done” to all tickets and closed them as “Done”. Needless, to say, the code failed to compile, which then meant that the rest of the team working on that same project could as well go home, as we could not do anything until bugs were fixed.

Hence, define ticket workflow and follow it. Also make sure that developers follow it. If needs be, by invoking mandatory flow and connecting it to commit messages.