How do I get developers to look at our bug tracking page regularly?

Question

We've recently started using Trac and are still trying to figure out the best way to use it in our environment. It's great, but it will only be effective if developers look at it once in a while and I'm trying to figure out how to instill that habit in them. I've contemplated several solutions, such as:

• forcing them to use Trac as their homepage (too draconian)
• handing out bookmarks to the RSS feeds (same problem--no one will look at them)
• automatic email notifications (won't drive them to the site and might just annoy them more than anything else)

What are some other solutions? What have you tried that worked?

Answer 1

Using Trac as homepage is quite impossible : what about the day you'll have several projects ?

The RSS/ATOM idea is not bad -- it works, on some projects, when all developpers use RSS frequently : it only means one more feed in their aggregator.

The solution I always use, though, is e-mails : it's fast, everyone knows how to receive e-mails and almost every developper will check those regularly.

Just configure the bugtracker so that enough information is put in the mails so each developper can determine in a quick glance to it if he should go to the bugtracker for more informations.

If you have too many bugs, a solution could be :

• When a new bug arrives, only one or two dispatchers guys get an e-mail
• They assign the bug to the developper that should take care of it
• And, only then, when a bug is assigned to him, the developper gets a mail

With this, each time a developper receives a mail, it means "there is some work for you".

After that, if they still do go to the bugtracker and don't fix bugs... Well, they are not doing their job that well, are they ?

Answer 2

Aren't the issues assigned to a developer, and then it is the developer's responsibility to fix it?

If you're assigning your developers tasks and they aren't doing the tasks, then you might want to consider finding some new ones that will listen to their managers.

Answer 3

How do you assign work to your developers?

I use FogBugz (by the makers of Stack Overflow). That has a Backlog feature that allows me to prioritize all bug reports and feature requests in the system from 1 to N across the entire company. Developers know to always work on the highest item in their backlog. There is no other way they can be assigned work (if someone walks up to them and tells them to do something, their automatic response is now "Is it in FogBugz? No, enter it and get it prioritized.") Took a while to get there, but now it works great.

You can probably do the same thing with Trac. The key is to have a single means of assigning work to your developers. If you expect them to look in multiple places to figure out what to do next, you expect too much.

Answer 4

This should be an integral part of your development methodology.

• Have daily (or regular) meetings where new bugs reports are inspected and assigned to a developer.
• Have all developers look at their own queue first thing every day. Make this a mandatory part of their daily routine. This is where their work is coming from. If they aren't looking at it, they aren't working.
• The project leader should monitor all queues to see if any developers are neglecting their queue.

Answer 5

One way that I have seen work...Require a defect ID in the comments for every check in to the version control system. Have a before filter on your version control system that rejects the change if no defect ID is there. It forces people to use the defect tracking system if they want anything to get to production and makes for change tracking.

One caveat, beware the "one bug gets all fixes" problem. This is easy to recognize and resolve though.

Answer 6

How does bug fixing fit into your overall development philosophy? Where I work, we'll have specific times that are where bugs are our focus so we just go bug squashing at those times and somewhat ignore it the rest of the time. It isn't a perfect approach, but it is a pretty good idea.

If you want something of the opposite end of the spectrum, I used to work somewhere that would have these daily bug triage meetings were whoever wanted to attend would come and some would pick which bugs they wanted to fix or make comments like this bug isn't that bad and can be left to a service pack project rather than fixing it for the initial release. Now, this was in a group where there were about 16 developers and the whole point seemed to be about who would work on what. It did get dropped a couple of weeks later as it didn't seem to be the best use of time for those doing it and really there were just a few managers that could handle prioritizing and assigning bugs.

---

Inefficient is an understatement about the second approach if you think about how much each developer is paid and most of the time just sitting around as really there may be 1-2 developers that care enough about a bug to discuss it with QA at this meeting. I'm posting about it here because I want to warn people against having this kind of approach as it can be much easier to have managers assign the bugs and if someone wants to know what to work on, refer them to the bug tracking software. That's a simpler approach.

Answer 7

I've worked on a few large projects as a developer and I always found the automatic email notifications to be the best. If developers do find them too annoying they can always redirect them to a separate folder that they can check at their leisure.

Another strategy that seemed to work but takes more time is to publicly reward developers that have a quick turnaround.

Answer 8

How do I get developers to look at our bug tracking page regularly?

Umm.... Tell them to.

I would consider staying up-to-date on the current state of a project part of my job description.

If you have to try and figure out how to convince your employees to do their job, you are either overthinking this or need to rethink your hiring strategy.

He who signs the check makes the rules.

Answer 9

We use e-mail notification, and it works well.

A related problem we ran into for a little while was that developers would fix a dozen or so bugs in one sitting, and then commit all the changes. This can be problematic, as it then becomes difficult to undo a single bug-fix. So the rule here is one bug report per commit.