Ask HN: What do you want/need from a bug tracking system?
43 コメント
Warning: my last corporate job was very heavyweight on the bug tracking
Things that are required at places I've worked:
Configurable workflows. An admin should be able to specify the allowed states in a bug, and the allowed transitions between states. If you do this, allow the set of required fields to change based on bug state.
Proper subtasks. It's really damned annoying to "support subtasks", but then not allow subtasks to have their own subtasks.
Things I want to see, that I haven't seen anywhere:
Merge tracking. At my last corporate job, we did a lot of branching and merging of source, and then the managers want to keep track of which branches/releases contain which bugs, so they can choose to port a fix over, or not. This process involves making a new bug for each port, saying "port bug #X to branch foo", which gets closed after the bug has been ported and tested on the new branch. The whole process is much more laborious than necessary. When the bug is filed, have the user report the first version that contains the bug. Then you can say all branches created after the first bug version (FBV) have the bug, and all branches that contain the fix don't have the bug.
Auto classification of component and severity. Many defect trackers have a field to track what part of the system has the bug UI, backend, etc. Many users don't fill out the fields. Use spamfilter techniques to guess at the component and severity based on the bug description.
Things that are required at places I've worked:
Configurable workflows. An admin should be able to specify the allowed states in a bug, and the allowed transitions between states. If you do this, allow the set of required fields to change based on bug state.
Proper subtasks. It's really damned annoying to "support subtasks", but then not allow subtasks to have their own subtasks.
Things I want to see, that I haven't seen anywhere:
Merge tracking. At my last corporate job, we did a lot of branching and merging of source, and then the managers want to keep track of which branches/releases contain which bugs, so they can choose to port a fix over, or not. This process involves making a new bug for each port, saying "port bug #X to branch foo", which gets closed after the bug has been ported and tested on the new branch. The whole process is much more laborious than necessary. When the bug is filed, have the user report the first version that contains the bug. Then you can say all branches created after the first bug version (FBV) have the bug, and all branches that contain the fix don't have the bug.
Auto classification of component and severity. Many defect trackers have a field to track what part of the system has the bug UI, backend, etc. Many users don't fill out the fields. Use spamfilter techniques to guess at the component and severity based on the bug description.
The ability to rapidly enter new tickets, from a single page. This could work if you want to import a crude todo list (from a meeting or brainstorm session) into the issue tracker.
Also make your issue tracker for more than bugs. Make it usable for features too.
Also make your issue tracker for more than bugs. Make it usable for features too.
I'm currently using it for features as well as bugs while I'm building it, so it should be gravy.
Also the quick add thing was the first thing I added as it's the main thing that annoys me with current systems.
Also the quick add thing was the first thing I added as it's the main thing that annoys me with current systems.
The advantage you have when building a tool like this is that you can "Eat Your Own Dog Food" and thus be your own user!
Might I ask why you're building "yet another" issue tracker? Whenever I think of a decent idea but find out there are already so many implementations, I reject it. Is that unwise?
Might I ask why you're building "yet another" issue tracker? Whenever I think of a decent idea but find out there are already so many implementations, I reject it. Is that unwise?
I needed one. Also the ones I looked at either didn't do what I wanted, or weren't suitable for clients.
Fozbugz has the rapid-enter ability BTW.
Offline mode. My SCM works in a train tunnel, but my bug tracker doesn't. Total pain in the backside.
Look no further than Fossil SCM. It had a distributed ticket system as well as a wiki, and it was developed by Dr. Hibbs (of SQLite fame) who provides unbelievable support for it: I saw him address a user's question on the mailing list within ten minutes this morning (Labor Day for posterity). And I'm using it for all of my projects now.
Another nice thing is that there's no notion of Git's "bare repository." A repository is a single SQLite database file, and you check out your working directory from it.
It also comes with a browser-based UI (no Tk) that includes the wiki, tickets, and admin. Oh, and it has an optional "autosync" mode that will push your changes immediately to a remote repository if you're connected.
In all, a high-quality piece of software.
Another nice thing is that there's no notion of Git's "bare repository." A repository is a single SQLite database file, and you check out your working directory from it.
It also comes with a browser-based UI (no Tk) that includes the wiki, tickets, and admin. Oh, and it has an optional "autosync" mode that will push your changes immediately to a remote repository if you're connected.
In all, a high-quality piece of software.
Keyboard Shortcuts - I use GMail's shortcuts, and prefer to avoid having to reach for the mouse when possible.
I want an integrated solution where I can manage bugs, feature requests and the prioritized backlog (containing both bugs and feature requests). Bonus points if it can manage incidents as well and help me to create bugs or feature requests from them. Oh, and I don't want to have to wait around for whole page reloads so nice slick AJAX for changing statuses et cetera would be greatly appreciated.
I agree completely with the hating refreshing, so consider that problem solved :)
I'll look into the other points, as I agree with them whole heartedly.
I'll look into the other points, as I agree with them whole heartedly.
- Ability to forward an e-mail to an e-mail address and create a ticket (bonus points if it can extract attachments and add them as attachments to the ticket)
- System tray app which I can quickly log tickets with - in-built screenshot util a must, even better if it could do screen capture video and convert it to a flash file or something.
- Well documented API / underlying database schema - so I can query whichever way I want for whatever reports. (Bonus points - have a page on your website which allows people to submit their custom api calls / SQL queries which other people can access - as you see common ones you like, you can quickly create a "top 25" reports package you can ship with your app)
- I don't want hosted only. I want to run it on my hardware. We're a windows shop, does it run on Windows / SQL Server - that's always good.
- Painless install & backup.
I agree with FreeRadical - most importantly, visual beauty.
- System tray app which I can quickly log tickets with - in-built screenshot util a must, even better if it could do screen capture video and convert it to a flash file or something.
- Well documented API / underlying database schema - so I can query whichever way I want for whatever reports. (Bonus points - have a page on your website which allows people to submit their custom api calls / SQL queries which other people can access - as you see common ones you like, you can quickly create a "top 25" reports package you can ship with your app)
- I don't want hosted only. I want to run it on my hardware. We're a windows shop, does it run on Windows / SQL Server - that's always good.
- Painless install & backup.
I agree with FreeRadical - most importantly, visual beauty.
This is a bit left-field, but I would love the ability to be able to edit tickets and comments for up to 10 minutes before they're made final and sent via e-mail.
Yes, please. This prevents the hail of spelling correction and minor edit emails.
Maybe be able to edit tickets up until another action is performed (status changed / comment added, etc...)?
An API would be good. Callbacks to external services would be useful too for notifying custom 3rd party apps of changes.
As a coder, I want a bug tracking system to work as a task list for me, and a repository for others. This is a hard dichotomy, but the ideal system would support it.
It's needs a command line interface or at least an open API, integration with Git, easy tagging & querying on tags, batch action tools that are easy (a-la GMail), and in-line editing / status-updates.
It also needs to deal well with a build process, and understand environments.
Good luck.
It's needs a command line interface or at least an open API, integration with Git, easy tagging & querying on tags, batch action tools that are easy (a-la GMail), and in-line editing / status-updates.
It also needs to deal well with a build process, and understand environments.
Good luck.
As a developer I've sorted most of these :)
A crossbreed between MantisBT (search/filtering power, subtickets/ticket-trees, "direct feel"), redmine (Interface cleanlyness, Gantt-Charts, SCM integration) and perhaps PivotalTracker (Ease of use, the "velocity" idea).
I could write a book about what rocks and sucks for each, but the take-home is that neither does everything right.
My main suggestion would be: Make it as modular as you can. This is imho the holy grail of such a system.
Example: When I don't use time-tracking then I don't want to see these buttons in the UI. Make sure "time-tracking" is a self-contained module that can be unloaded and not a series of conditionals in your codebase.
The goal should be to have a a very slim core with a plugin-system so powerful and easy that people will start writing the interesting features for you. Everything should be a plugin.
I could write a book about what rocks and sucks for each, but the take-home is that neither does everything right.
My main suggestion would be: Make it as modular as you can. This is imho the holy grail of such a system.
Example: When I don't use time-tracking then I don't want to see these buttons in the UI. Make sure "time-tracking" is a self-contained module that can be unloaded and not a series of conditionals in your codebase.
The goal should be to have a a very slim core with a plugin-system so powerful and easy that people will start writing the interesting features for you. Everything should be a plugin.
1) Easy input, minimum number of mandatory fields (2 is quite optimal: "subject", "steps to produce")
2) Fast as hell. It's one of the most used dev tools. (Trac fails in this)
3) Hassle-free way to add screenshots, log files, etc. And it should show screenshots inline. (E.g. Trac fails in this)
2) Fast as hell. It's one of the most used dev tools. (Trac fails in this)
3) Hassle-free way to add screenshots, log files, etc. And it should show screenshots inline. (E.g. Trac fails in this)
Find the right level of simplicity and lock it frack'n down, someone thought of about 30 super-important fields to add to bugzilla, maybe one is used, but probably shouldn't be... just makes navigating dense, annoying and slow.
Have you spent significant time looking at plug-in schemes, such as those of Trac? I think you'd be better off writing simple extensions to well-established systems, than making an entire replacement system. This has two benefits:
- People using the established system are more likely to try your add-ons for your unique features. (Whereas, replacing a system outright is unrealistic in a short timeframe.)
- You will have less work to do, as you can focus on the things you've "not seen in other systems", instead of having to do everything.
- People using the established system are more likely to try your add-ons for your unique features. (Whereas, replacing a system outright is unrealistic in a short timeframe.)
- You will have less work to do, as you can focus on the things you've "not seen in other systems", instead of having to do everything.
Please do steal features that trac or redmine are great of.
And if you plan to make it open source, please make it easier to install than trac.
And if you plan to make it open source, please make it easier to install than trac.
Organising issues in a reciprocal "depends on"/"blocks" relation. It makes it easier to identify bottlenecks. BugZilla does it, but I havn't found any lightweight system that does it.
When it comes to things with levels such as severity or priority keep the option list short, 3 to 5 items. Preferably with user configurable text.
Allow bugs to be grouped into meta bugs. Bugzilla had a feature that showed a tree of bugs that was very nice (almost the only good thing about it).
No admin interface! I've just about had it up to here with some PHB having admin on a system and then disappearing into meetings for the next three months :( Everyone is an admin :)
Allow bugs to be grouped into meta bugs. Bugzilla had a feature that showed a tree of bugs that was very nice (almost the only good thing about it).
No admin interface! I've just about had it up to here with some PHB having admin on a system and then disappearing into meetings for the next three months :( Everyone is an admin :)
I've just about had it up to here with some PHB having admin on a system and then disappearing into meetings for the next three months
Alternatively, make the interface usable from a Blackberry or via email.
Alternatively, make the interface usable from a Blackberry or via email.
Command-line interface and/or API for making such.
I'm using rt right now. I like using its interface, but there are others on my team who never log in through the web; they update tickets solely via e-mail.
It would be nice if they were able to change metadata of the ticket (new, open, resolved, etc) via e-mail.
It would be nice if they were able to change metadata of the ticket (new, open, resolved, etc) via e-mail.
As what some already said,
1 "the new ticket form" should render fast and easy to figure out. It would be great If there's bookmarklet or simple browser plugin or mobile app that's just render this form.
2 Live twitter-like feed on top level features/stories would be handy for me.
1 "the new ticket form" should render fast and easy to figure out. It would be great If there's bookmarklet or simple browser plugin or mobile app that's just render this form.
2 Live twitter-like feed on top level features/stories would be handy for me.
Optimize the basic cases for speed. Not needing to touch the mouse (as MrMatt points out) is a good start. If you make it dead simple and lightning fast to open, close, and forward defects, you'll win a lot of fans.
A css-able widget to put on our site so there can be easy direct customer input I can keep track of as tickets along with the other stuff we track internally.
A generated auto-login link where clients can easily fill in bugs.
I want the bugtracker to become invisible in my usual workflow: I read and edit to-do lists and code in Emacs, and any bugtrackery things happen implicitly.
Email driven everything ala posterous.
visual beauty
What I want is not another one, there are plenty of them already.
An unpretentious proprietor
A command line interface.
Now this is not to sound stupid, nor because I have an unhealthy relationship with Bash. What I mean is something like google: most people just enter their queries directly into the bar, and it just works - your software should too.
Then there are a few power users, who take the time to learn that you can improve you results with a few extra additions.
One example would be the use case, where I have discovered set of bugs that are properly in Freds code, so I want to assign them to him; it would be very useful if I could write something like this: "Components not aligned in about box;;as fred; pri high". Basically steal the google interface and allow people the maximal freedom to work with the software.
Now this is not to sound stupid, nor because I have an unhealthy relationship with Bash. What I mean is something like google: most people just enter their queries directly into the bar, and it just works - your software should too.
Then there are a few power users, who take the time to learn that you can improve you results with a few extra additions.
One example would be the use case, where I have discovered set of bugs that are properly in Freds code, so I want to assign them to him; it would be very useful if I could write something like this: "Components not aligned in about box;;as fred; pri high". Basically steal the google interface and allow people the maximal freedom to work with the software.
Localization. We recently set-up a bug tracking tool for someone who was sending bug reports to an external developer as Word documents, and we picked Mantis because it supported Hebrew (as well as being free and relatively straightforward to install).
Now what I want to know is, are there certain features that you look for in a bug/issue tracking system or is there anything you'd like to see in one?