Ask HN: What do you want/need from a bug tracking system?

SCM integration - linking to commits and changing the states of tickets via commit messages.

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.

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.

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.

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 :)

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.

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)

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.

visual beauty

An API would be good. Callbacks to external services would be useful too for notifying custom 3rd party apps of changes.

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.

- 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.

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.

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.

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).

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.

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.

Offline mode. My SCM works in a train tunnel, but my bug tracker doesn't. Total pain in the backside.

What I want is not another one, there are plenty of them already.

Email driven everything ala posterous.

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.

Command-line interface and/or API for making such.