
Ask HN: What do you want/need from a bug tracking system? - Jim_Neath
I've been working on a bug/issue tracking system for the last few months. I'm hoping to launch in 2 or 3 months. The current feature set is pretty basic, with a few things that I've not seen in other systems, that I think make it easier to use for both developers and clients.<p>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?
======
MrMatt
SCM integration - linking to commits and changing the states of tickets via
commit messages.

~~~
Jim_Neath
I've currently sorted out integration with Github. I'll look into integrating
with Subversion and others if there's enough call for it.

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

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

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

~~~
wlievens
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?

~~~
Jim_Neath
I needed one. Also the ones I looked at either didn't do what I wanted, or
weren't suitable for clients.

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

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

~~~
davidw
Dr. Richard Hipp, not Hibbs, BTW. He's also a member of the Tcl core team.

~~~
erlanger
Oops :)

------
MrMatt
Keyboard Shortcuts - I use GMail's shortcuts, and prefer to avoid having to
reach for the mouse when possible.

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

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

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

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

~~~
randallsquared
Yes, please. This prevents the hail of spelling correction and minor edit
emails.

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

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

~~~
Jim_Neath
As a developer I've sorted most of these :)

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

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

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

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

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

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

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

~~~
randallsquared
_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.

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

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

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

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

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

------
radu_floricica
A generated auto-login link where clients can easily fill in bugs.

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

------
buro9
Email driven everything ala posterous.

------
FreeRadical
visual beauty

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

------
falsestprophet
An unpretentious proprietor

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

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

