It is disappointing to me that the best Bug Trackers out there are web applications that you can’t access the source to. It is disappointing, because these web applications often lack some feature that make open source bug trackers great. The best of these that do combine the best of both worlds require payment and often have more features than most require.
I think the problem has always been that bug trackers have been built by programmers for programmers based on specifications that the programmers thought others would require, need or comprehend as useful. There are basic features for organization of bugs or tickets, but most of the time these are made for programmers. An user doesn’t really know what milestone or version the ticket will be completed, they might not even care. They probably don’t know how the administrators define each component and I doubt most really care.
The key element of most web bug trackers are that they are simple and easy. They remove most of the cruft and useless features that plague open source and other more complicated bug trackers. The break it down to the fundamentals of tracking bugs and leave you to have at it. Most of the time this is all you will need. When you get to the point where the basics are no longer cutting it for you, then either more features are being offered by the service or you move on to a more advanced platform.
I want something like this in an open source product that can be easily and quickly extended. I want something that takes the best of Trac, Get Satisfaction, 16 Bugs and maybe some of Fog Bugz.
Goals
The goal is to look at what makes these web applications great and include them in one package for people to use and hopefully extend. The goal is to also allow for enabling and disabling features as they are needed. If all you need is a 16 bugs (which is really more of a Basecamp clone), then well, that is what the basic package will be and you simply don’t enable any of the other features.
Features like roadmaps, components, reports, searching etc from Trac can be enabled, customized and configured later. However, what the web application will never be is anything more than a simple, but extendable bug tracker. There won’t be a Wiki, you would instead link to one, but I do hope to have some support for built-in linking of wiki, similar to the Trac feature.
Get Satisfaction
Looking at Get Satisfaction, I can really see why it will become popular in the future for a bug tracking web application. It is simple. Really incredibility simple, but well there are some navigation problems, but they are so minor that navigating the web site after the initial learning curve is not an issue.
It does what bug trackers should have been doing and really, I think you have to see it in action to realize its effectiveness. It allows you to not allow list problems, but also questions, request features and give praise. I think why it is so great needs a little bit of explanation, in case you don’t realize it already.
Why is giving praise important?
It tells the developers what people think they should be working on. It tells the developers and people making plans for the next release what features really made a person’s day; the one feature that sold the product for them. It also continues motivation for open source projects where no money is being made. It is really kind of depressing to read over defects all day, but with this feature on the site, people can tell you how much you helped them and that they care.
Why so simple?
If you think about it, what does the customer or user really care about? They really only care about telling you what the problem is and then leaving. Thinking about it some more and Trac is really setup to be confusing. How many people know which component a ticket belongs to? 1 or 2, 0 if the person who set them up was just winging it. How do you set the component when the ticket might belong to several? Throw darts most likely. What about the roadmap? Everyone thinks their ticket should be completed before the next release, but how often does that happen?
The power of Get Satisfaction is that it doesn’t burden the user with the minute details that really only the programmers care about or even know. It allows the customer or user to get in tell you about their problem and leave. In some ways Lighthouse is extremely similar, but mostly geared towards only defects and features with a bit of Trac thrown in for good measure.
I do like the bit about Giving Praise, along with asking for features. I’m thinking about including it. It won’t be that difficult to add and will work similar to everything else. It will just be a matter of allowing the administrator to disable it if so desired.
Problems of Get Satisfaction
I think Lighthouse solves many of the organization problems with Get Satisfaction. The major and only problem I can see with Get Satisfaction is the lack of milestones or separation of tickets. It is just one big list and when you have many tickets, praise, and feature requests, it can be a little overwhelming to go through them all. The other problem is the matter of duplicates. It is either difficult or impossible to mark something as a duplicate of something else.
Project Management
The strength of Fog Bugz is its project management and well, their other features as well. The initial version, I’m not going to focus on Project Management or Agile features, unless more time comes up.
I do think that this is what Trac is lacking. It is difficult to get metrics on what people want, on what people have done, how close the project is to being completed, etc. Reports and graphs are one aspect of this. The other is figuring out what programmers should focus their time on.
In my product, I want to initially focus on completeness of bug and feature tickets. I want to include ticket dependencies for features and bugs. I want a metric for whether a bug or feature is complete and for this I want a report that tells programmers which tickets they should be looking at.
Reporting
Ticket Completeness
The term ticket completeness is the workflow of the ticket from the initial report from the customer or user to the time is fixed or included into the project. It does not include tickets that are closed for being invalid or another reason.
- How Detailed is the Report? Does it include a detailed or proper description? Does it include correct steps to reproduce the issue? Does it include a workaround? Does it include Expected event -> Actual event descriptions?
- Does it have Attachments? Does it include a patch, a prototype, screenshots and, or other helpful files for reproducing or understanding the problem or feature?
- Does the ticket have comments? Are the comments helpful, debating the issue, or querying for more information? Do the attachments have comments, requests for feedback? Have the patches or prototypes been accepted?
- Does the ticket, defect or feature, have up votes telling the programmers what the users and customers care about?
- Has the extra information been completed: things like roadmap, version, OS, etc
- Time the ticket has been active, time the ticket has been opened, time the ticket has been stale.
In a perfect world, every ticket will receive feedback within 24 to 48 hours. Whether it is a comment saying the ticket has been looked at and, or reviewed or a patch has been submitted. It is possible to include some of these feedback mechanisms into the web application. Whether the ticket has been looked at will include whether the core team has looked at the ticket or patch or whether a trusted member has looked at it or if someone else has looked at the ticket. These are easy features to include and might have some pay off for the reporter.
This is really to tell the programmers which tickets are not receiving proper attention given the other criteria. It will also inform based on how complete the ticket is. If a ticket has a patch and the patch has not been reviewed, then why not based on a given number of days?
Giving programmers and contributors information to make wise decisions.
The programmers managing the project and the contributors should be able to see which tickets are being addressed and how well. They should also be able to quickly find tickets that haven’t received proper feedback and tickets that can possibility go into the next release.
I think this is the first step to project management features. The reports will be built-in, but completely optional. The emailing to the reporter on updates will also be optional and will be a single check box. The key will be to gradually give the reporter the impression that their ticket is being addressed and help the programmers address tickets.
Possibly Related Posts: