Read Joel Spolsky's painless bug tracking, linked from point 5 in the Joel test (look at the other bullets there too while you are visiting). You might also want to see what this article looks like in your native language: Joel provides lots of translations.

Here are some things to think about

• How much do you need for this project? What functionality is critical? What functionality would be nice but not necessary.
• How many bugs do you think you may have to track? How much space will they occupy?
• We don't have a lot of money to buy something. We may have some.
• We won't have remote access to anything running on UMass PCs.
• You may recommend a web service - a place that stores the bugs on their site and gives you access through a browser. If you do, you should consider how/whether you can archive some bug information locally too.
• You can probably install any (free) software on Unix that does not require system privilege or need access through the firewall.
• I will find out whether the local ticket system used by Operator is available. (You can try man req on Unix to find out a little bit about it.)
• You can consider my rptbug package. (Documentation in ~eb/rptbug/bin/rptbug.doc, which is text, not MS word.) But I don't think I'd recommend it. I don't guarantee to support it.
• You may recommend quickbase. Paul English will explain how to set up a free database there when he speaks next week.
• You should look at sourceforge, even though we probably won't be able to use it. I inquired there and got this interesting response. You can tell that they are using their own tracking system.

• http://www.project-management-software.org/tracking/ - annotated index of more or less free stuff

• easybugtracker - free for limited use, web based.

• teamatic - free for limited use, web based.

• FogBUGZ - excellent, not free, and you need to run your own windows server. So it's not for us, but it's worth looking at.

Back to the cs681 home page.