How do you track bugs in your personal projects? [closed]

Question

I'm trying to decide if I need to reassess my defect-tracking process for my home-grown projects. For the last several years, I really just track defects using TODO tags in the code, and keeping track of them in a specific view (I use Eclipse, which has a decent tagging system).

Unfortunately, I'm starting to wonder if this system is unsustainable. The defects I find are typically associated with a snippet of code I'm working on; bugs which are not immediately understood tend to be forgotten, or ignored. I wrote an application for my wife which has had a severe defect for almost 9 months, and I keep forgetting to fix it.

What mechanism do you use to track defects in your personal projects? Do you have a specific system, or a process for prioritizing and managing them?

Answer 1

Fogbugz (free individual license) if its a longish project or a simple to do list (using Google tasks)

Answer 2

I usually use a web based revision control system(Github, Bitbucket, Redmine, Google Code, ...) to store my source code and track bugs. If you think there's a bug in a specific code, you can create an issue with the revision number/changelist/changeset and specify which file and the range of lines you suspect.

Answer 3

I used to use a spreadsheet/text file per project (ToDo comments in the code don't scale well for the reasons you list; they're local to the code, and if there's an issue that's not, it tends to slip through the cracks).

Recently I've set up a Redmine server on my home network. It's a bit heavyweight for a "team" of one, but I'm working on quite a few projects on my own time, and tend to just use the Issue Tracker + Repository options with maybe the odd wiki page in more complex places.

A friend of mine swears by Pivotal Tracker for the same purposes, but my current employer uses Redmine internally, so I figured this would give me some practice. It's not bad.

For open source projects, I just use GitHub's issue tracking.

Answer 4

I've actually installed the Free MANTIS bugtracker system on my hosted web server (that I use for a blog and other things), and put all my defects in that.

In other words I run my stuff as though it were professional and paid for.

I find it helps keep a better mindset (closing off defects, etc) as well as being consistent (ish) with other practices commonly used in industry.

Use TODO notes in code, etc, as well - but only for notes top self like: "one day I gotta make this more efficient, the bubble sort hurts performance". Or for more immediate notes about where you got up to when you were hauled off for dinner :)

Answer 5

I use ToDo List program, an open source code from codeproject

http://www.codeproject.com/KB/applications/todolist2.aspx

Very nice and with many features.

Answer 6

We use JIRA at my workplace and I'm a big fan of it. Lots of products and people involved and it manages it all just fine.

Answer 7

I came looking for an answer for this a while ago and have since worked out a very neat and simple system, which meets these key goals for me:

Goals in order of importance:

1. Make it possible to enter a new task/bug as effortlessly as possible, so that I can jot it down as soon as I spot it or dream it up, and go back to coding before I lose my place.
2. Make it easy to see and manage the issues without a lot of searching, clicking, drilling down.
3. Make it easy to tie in with version control so I can later find out what changes were made to resolve an issue, or what task or bug drove a specific change in the code.
4. Make it relatively easy to set up: minimal installation and configuration and minimal price.

(3 and 4 are less important, and I would have been okay with a system that didn't provide them, but this one does).

Step 1: Get a project in Bitbucket

I use bitbucket for issue tracking and for git version control (for an iOS project in XCode for example). I looked at FogBUGz (which I've read about for years on JoelOnSoftware) and GitHub and others, but bitbucket seems to have the best free features set for small teams.

Step 2: Use Bitbucket Issue Tracking in the project

Next I set up issue tracking in the same bitbucket project. So my project now has a git repository and issue tracking.

Step 3: Make issue tracking easy!

For this I'm using Bitbucket Cards which is a nice, simple kanban-like front end to the Bitbucket issues. You just have to log into your Bitbucket account and set up the columns you want. I have four columns: Backlog, Next, Bugs, and Resolved. (I'm thinking of merging Bugs with Backlog, but never mind that for now)

(This image is from the Bitbucket Cards blog, not from my project, hence the columns are different than the ones I use)

Bitbucket Cards lets you set up a very simple filter for each list where you choose the status(es) and kind(s) of issues that go in a card column. So, open status issues of the kind bug go in the Bug column.

(This one is from my project: that's how I select what goes in the Bug column)

What's really cool is that when you drag and drop a card from one column into another, it will automatically change the status of the issue the card represents to match that in the definition of the destination column.

Another nice thing about Bitbucket Cards is that it doesn't time out easily. This is crucial since the aim of this whole set up is to make it easy - so this system works for me instead of me working for it. I open a bookmark my card page and it stays open on a Chrome tab all day.

This takes care of my 2nd goal.

Step 4: Tie it in with version control.

Bitbucket issues tie in neatly with version control (as to most of the competitors) so when I'm finished working on an issue I commit it git with a message like "Added the thingo to the whatsit. Fixes #245". If I commit this, then push it, then reload my Bitbucket Cards page, I'll see that the issue has moved to the Resolved column. Cool.

There's my 3rd goal done.

Step 5: Make it easier to CREATE issues.

You probably think that this whole set up is already way to complicated to set up, and why would I want to add another web app to the process. Well, remember my primary goal above: I want to make it so easy to add a task that I don't lose my train of thought before I get to the text area to type it in, nor do I want to lose my place in the code by the time I get done.

Now, Bitbucket Cards does let me create tasks fairly easily, but it's just a bit to clicky/scrolly to fully meet goal #1. You have to click Create an Issue; then a modal editor pops up; after entering your issue title you have to scroll down to specify the kind (bug/task) and the priority; then click create.

Instead I chose to use a second Bitbucket app called taskrd.

You can set up taskrd, by giving it your Bitbucket login, and set it on a bookmark and tab, and keep it open all day, just like Bitbucket cards. Taskrd has a much simpler workflow for adding a new task, just type it in, optionally set the kind and priority, and hit the Add button.

(this image is from the Taskrd blog)

Now it's arguable that it's not worth the effort of setting up Taskrd over using Bitbucket Cards or even Bitbuckets own issue-entry system. After all, with Taskrd I have to click a tab on my browser, and click Reload on my page with Bitbucket Cards for it to refresh and get the new issue I added in the Taskrd app. But in fact, I find that I'm generally in mode or the other: Either I'm using Bitbucket Cards to organize what I'm doing next, or to look through the bug list, or I'm busy coding and entering tasks/bugs as they occur to me - all in rapid fire mode. For this 2nd mode of work, the Taskrd is great: I just keep it open on a separate monitor, and quickly enter issues as I work.

So that covers goal #1.

My last goal was easy/cheap set up. Well cheap it is: all of this is free. Bitbucket has free private repositories for up to five users and the other apps were free. Setup seems non-trivial based on the above, but really the most complicated part was setting up git to push to the bitbucket repository which will be the same anywhere. I didn't have to install anything, and connecting both of the apps to my bitbucket repository was pretty easy. Setting up the cards columns how I liked them took a bit of playing around but wasn't really hard.

Reading this back, I might come off as a bit of a shill for Bitbucket - but I really don't mean to. It's just that I've been using this process for weeks - after years of trying different configurations to track what I'm doing - and I'm really digging it, so thought I'd take the time to lay it out for others.

Answer 8

If you're familiar with using TODO tags in Eclipse, a simple step up would be to use Mylyn. At it's most basic, it's a simple todo list. But, it also associates context with tasks - click on a task to activate it, do some stuff, and then next time you activate it, Eclipse will open up the relevant classes, and show you the relevant methods. Even more powerfully, if you eventually move to some other bug tracking system, Mylyn can pull tasks from those systems and present them in your IDE.

Most Eclipse downloads these days have Mylyn bundled in as standard. Just search out the Task List view and start adding tasks.

Answer 9

I use the $10 starter license for Jira. It's cheap and I already know it well from work.

Answer 10

Like others here I use either a text file or the bug tracker built into whatever dvcs hosting service.

Lots of it depends on what sort of "personal project" it is. Is it something that is ever going to see the light of day or is it just an experiment? Is this project in use by the public?

For example, one of my personal projects became moderately popular and setting up a Get Satisfaction site for it worked really well. Not really "bug tracking" but it worked great for bug/feature requests.

Answer 11

Kinda surprised no one has said this yet, but there are distributed bug tracking solutions which act as part of your distributed source control i.e. the bugs database lives with your code in your revision control. Well known implementations include "Bugs Everywhere", Fossil and Ditz.

See https://stackoverflow.com/questions/773818/distributed-projectmanagement-bug-tracking and https://stackoverflow.com/questions/1851221/distributed-bug-tracker-to-go-with-dvc?rq=1 for a discussion.

Answer 12

For my personal projects I use Omnifocus.

Update:25/10/2010 If i find a bug that I can't or don't want to fix immediately I quickly add it to the Omnifocus inbox. Then later, when I'm doing a review I will gather all the info that I think I will need to fix the bug and then add it to the project. It's position in the task list indicates it's relative importance.

I treat bugs the same way as requirements/features in most respects.

Answer 13

For personal projects, TODO-comments and a text file with TODOs and bugs etc. is usually enough for me.

Answer 14

I use my own TheKBase (since I'm on OSX, I use it on .Net in a virtual machine or Mono, depending on my mood). For one concurrent user only, but: It allow for multiple hierarchies, so it goes from task manager to information manager missing no steps in between. Plus it's open source on Github and free (that's obvious, I guess).

For the curious, instructions are here.

Answer 15

I use ToDoList for my personal projects; it's lightweight, free, and has plenty of features. Not sure how well it scales for team projects, but it's great for me working by myself. I'm not sure how I survived using Visual Studio's built-in task list for so long, it's crap.

Answer 16

We use a combination of JIRA and Google Docs and Spreadsheets. I looked into other tools as our JIRA installation is older than dirt and not as easy to use as the newer, fancier, drag and drop interfaces.

I looked into Manymoon, Zoho Projects, Insightly, Redmine, and Assembla. We're going to experiment with the Assembla free Stand Up tool. It's a very simple 3 field reporting interface that asks each team member 3 questions: What did you do last week? What will you do this week? What barriers are in your way?

In the end, I think I'm going to stick with JIRA, Google Docs, and the Assembla Stand Up tool, as the combination gives me everything I need.

Answer 17

I like Trac the most, because it's lightweight, easy to use and easy to configure. And the integrated wiki and the elegant repository browser are a big plus.

At work we use JIRA, which is also quite nice, but not so easy to administer. And I really miss a wiki (integration with Confluence is not so great) and a good repository browser (we just have ViewVC).

Answer 18

I've been using Trac for the past few years. I've used Bugzilla and JIRA as well. My personal and private consulting projects involve Trac simply because I'm used to it and to get a project going in my personal dev setup takes so little effort because the effort is over with. I've got trac connected with all I need including SVN or Git and Hudson(or rather Jenkins now).

On some client projects there is generally no choice but what they use, which often enough is nothing or some in house crap unfortunately. I'm surprised when they have a bug tracker lately. Personally though, I'm looking forward to a better offering from the OSS community than Trac. It gets things done but these days seems like such a patchwork.

Answer 19

I don't see the point in using formal bug tracking for small one-man projects. Usually I just keep a (very short) mental list and fix the bugs as I become aware of them. Of course this doesn't scale for large/multi-person projects, but the point is that it doesn't need to.

Answer 20

If you use ReSharper, it has a TODO tracker, which shows you a list of all TODOs, NOTEs and BUGs in your solution. It also highlights them in your code in any colour you choose. I find this really useful on my own projects.