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?
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.
Also make your issue tracker for more than bugs. Make it usable for features too.
Also the quick add thing was the first thing I added as it's the main thing that annoys me with current systems.
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?
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.
I'll look into the other points, as I agree with them whole heartedly.
- 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.
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.
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.
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)
- 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.
And if you plan to make it open source, please make it easier to install than trac.
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 :)
Alternatively, make the interface usable from a Blackberry or via email.
It would be nice if they were able to change metadata of the ticket (new, open, resolved, etc) via e-mail.
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.
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.