Flyspray: One of those web-based bug tracker

Working with Mantis has been sweet. It was a project manager’s delight – full-blown features and a powerful back-end.

However, if you are concerned with usability, it can be a nightmare. Getting Mantis to display the barebones essentials required too much editing. Mantis, after all, doesn’t (yet) have a templating system to make it easier to customize & remove fields.

Task type (bug, feature, task) wasn’t also built-in – custom fields have to be used (which will prove later on to be a templating horror), or maybe recycle the not-so-often used Severity field.

Most agonizing is in customizing the “look” of Mantis. It is bursting in the seams with its sheer number of tables …. probably to make up for its pitiful number of CSS classes?

Enter Flyspray

Flyspray came to the rescue. Well, sort of. All the pertinent fields are in plain view – due date, target version, percent completed, and yes, task type.

It is also highly customizable – numerous classes & ids are meticulously included to make the CSS fanatic in you real proud. In a short amount of time, I was able to transform Flyspray’s horrendous default template to something utterly glorious.

Exit Flyspray

Upon entering more data, however, Flyspray’s weakness started to kick in:

The actual editing of global & project permissions leaves much to be desired. It took a lot of hits & misses before we finally figured out the difference between the project & global permissions (even where & how to edit them, for that matter).

A function similar to Mantis’ My View or Trac’s My Tickets was conspicuously missing. This is a page where users can see all the issues assigned to them, regardless of project. In the forums, however, we were informed that this is not needed, as there is an advanced search feature which can be used to search for tasks assigned to them. Oh … oh okay.

Most painful is the lack of support for subprojects. I’m still wondering if the Flyspray team never realized that people with more than 20 projects will want to use their product. Unfortunately, I am one of those people, and I have to play with prefixes just to get those damn projects ordered right. And did I mention that the project switch drop down is now extending near the end of my browser window? Really.

Meenie, minie …

If you are part of a small team (maybe 5 people) and handling a couple or so projects … yes, Flyspray would probably perfect for you. However, they are not for developers of medium sized to large teams, those handling more than 5 projects, and for Project or QA Managers who use bug trackers intensively for issue, assignment, and project tracking.

Don’t expect much in the future developments either. Based on their roadmap and posts in the forums, their primary customers are the self-managed developers.

And we are left with no choice but to pray to the highest heavens that someday, somehow, the developers of these bug tracking systems will finally listen to the users who actually use it the most.

Issue Trackers: An indispensable development tool

There is one application that a development team depend a lot on — to the point that it is accessed almost every hour: the Issue Tracker.

Before we go on the nitty gritty details of an issue tracker, let’s first discuss what an issue is.

What is an issue?

There is no simple answer, because every organization has its own definition. However, depending on your company’s methodologies, development cycle, and culture, an issue can be any (or all) of the following:

  • a bug
  • a feature
  • a change order
  • a requirement

In our organization, we define issue as a bug or an approved change order.

This has raised eyebrows from the most conservative project managers (PMs). However, we believe that this is necessary to provide a healthy balance between speed & process. Think about it: during crunch time, would you really expect the programmers & the QA team to constantly refer two tracking tools at the same time? Having one tool which keeps all to-do lists provides a simple yet workable system for a team.

What is an issue tracker?

From the name itself, an Issue Tracker is a system which lets you track the status of an issue. Its status can either resolved, closed, needs feedback, assigned, etc.

How does it work?

The workflow starts with a person entering an issue — he can be the project manager, a QA staff, the customer, or even one of the programmers.

The project manager or the QA then confirms it: Is really a bug, or a change order? If it is a bug, was he able to replicate it? Is the issue too vague that more information is needed?

After confirming the issue, it now has to be assigned — to designate the person responsible for it (usually the programmer). The project manager, QA, or even the programmer can assign an issue.

As soon as it is assigned, it is now included in the list of tasks of that person (“assignee”). It will keep on appearing in his to-do list, until he marks it resolved.

If an issue has been marked resolved, it is verified by the QA or the PM, and then is tagged closed.

Uses of the issue tracker

From this workflow alone, you can already guess the numerous uses of an issue tracker. It can be used to:

  • generate status reports
  • provide metrics on the rate of resolution
  • provide a basis for work breakdown structures for future projects

Issue Trackers

Numerous issue trackers are available, both commercial and freeware. If you want to go thru the open source route, there is Bugzilla, Mantis, dotProject, etc. Almost all project management applications already have an issue tracker built-in.

Things to keep in mind

In selecting an issue tracker, workability & acceptance is key. The tool must be something that your team is willing to work with. I handled an enterprise level project wherein we simply used Excel — because that was what the team wants to work with.

The biggest mistake of most PMs (this author included) is forcing a system she thinks is “cool” to the other team members. If, after a few weeks of using the tool, you sense reluctance from your team, take the hint. Reevaluate the different options available until you find one which works best for your team.