|
[ Help Index ]
Feature Guide
Email Notification
Projects and Areas
Releases and Versions
Filters
Estimates
Mailboxes
Using FogBUGZ for Customer Bug Reports
Email Notification
When a bug is entered or changed, FogBUGZ automatically sends an email notification to the person it is assigned to. In addition, anybody who has subscribed to the bug (by clicking the link at the bottom) receives a copy of the notification. There is one exception: to avoid clogging your inbox, FogBUGZ will not notify you of your own actions because, presumably, you already know about the change since you made it yourself!
Anybody can turn off email notification in the Prefs screen, although this is not recommended, and never get an email from FogBUGZ. You might want to do this if you check FogBUGZ as often as you check your email. It's also useful for "pseudo-accounts" that you create that don't correspond to real people.
Email notification requires an SMTP server. To turn off email notification system-wide, an administrator can set the SMTP server to NONE in the site configuration screen.
Back to Top
Projects and Areas
Each installation of FogBUGZ can be used to track multiple projects. Within each project, you can divide cases into areas. Anyone who is an administrator can create and edit projects and areas.
Every project has a primary contact. When someone enters a new case, they usually let it be assigned to the primary contact, who should be the person responsible for looking at the case first and assigning it to the appropriate person to fix. If you are working on a large project team, you may want to have several people who all help categorize new cases. To do this, we suggest that you create a user called "New Case" and make that user the owner of the project. Then anyone who wants to help sort through new bugs can create a saved filter on "all bugs assigned to New Case" which they check occasionally.
What areas should you use? The best approach is to start with just one area, called Misc, which holds all the bugs for the project. Then add areas only if they are needed for a particular filter you want to create. For example, if you have a team of technical writers and they want to be able to see all the bugs in the documentation, create an area called Documentation. Don't create more areas than you need for filters, because the more you have, the more likely cases will be misfiled. If you have more than half a dozen areas, you will find that people start to be confused about which area a case belongs in. (In fact that's the main reason only administrators are allowed to edit projects and areas).
Back to Top
Releases and Versions
Each project in FogBUGZ can have a list of releases. These are basically just milestones associated with dates in the future. For example, a typical software project might have milestones of Alpha, Beta, Release, Service Pack 1, etc. Once version 1.0 has shipped, you may have 2.0, 3.0, 4.0 releases planned. Once you add releases to a project in FogBUGZ you can assign a given case to be "fixed for" a given release. When a release is coming up, you can create a filter listing all cases that must be fixed for that release. You can also create releases without dates, for example, "When Pigs Fly" or "Undecided" or "ASAP".
You can also create releases that are usable with any project. FogBUGZ ships with "Undecided" as a useful default release. You can also use global releases when there is an event coming up by which time certain bugs need to be fixed in a bunch of projects. To edit these global releases, go into any project.
Cases include a field called Version which is meant to be used to indicate which version of the project a particular bug was found in. There are probably a lot more versions than releases; many programming shops have builds every day and it is helpful in reporting a bug to indicate exactly which build it was found in. That's why the Versions field is just free-form text. When you enter a new case the default version will be the same as the last case you entered; this way if you are testing a particular version of code and you find lots of bugs you don't have to keep reentering it.
Back to Top
Filters
The real power of FogBUGZ comes in defining and saving filters that correspond to the things you care about. For example, you may want to create a filter of all the bugs assigned to you, a filter of all the bugs that you opened which are still not resolved, a filter of all the bugs in the upcoming release of one project, a filter showing bugs which you need to estimate, and so on. Once you get the filter right, go back into the Filter screen and save it with a memorable name. It will appear in the My Filters menu on the top of every screen, allowing you to quickly get a list of cases matching your criteria.
Back to Top
Estimates
FogBUGZ 3.0 is intended to keep track of all developer tasks, not just bugs. You can use it to track features that need to be implemented just as easily.
To help make estimates of when the project will be complete, FogBUGZ lets you enter an estimate for any case. An estimate is given in days and hours. You type it in using the form 1d4h, for example, which means 1 day 4 hours. Both parts are optional; 8h is considered equivalent to 1d; 12h is the same as 1.5d or 1d4h.
You can use 0.25h for a quick, fifteen minute case. The only thing you can't enter is 0, because that is indistinguishible from "no estimate at all." Using filters, it is easy to search for all the bugs without estimates so you can add estimates.
If you ever change an estimate, the original estimate is remembered next to the current estimate. That is useful if you want to go back to your old bugs and see how good a job you've done estimating in the past, so you can learn to estimate better in the future.
Once you enter a non-zero estimate, you can enter the elapsed time, and FogBUGZ will automatically calculate the remaining time. For long features which take several days, at the end of every day's work, you can reenter your current best-guess estimate and the amount of time spent so far.
Back to Top
Mailboxes
FogBugz can read the contents of any email inbox, and convert each incoming mail message into a case. You might use this to provide an easy way for staff or outside customers to enter bugs: "just send an email to
bugz@example.com and it goes right into our bug tracking database!" Another use is to keep track of all the email that comes into company mailboxes, like webmaster@example.com or
info@example.com. New mail comes in, becomes a bug, and you can make sure that somebody responds to it or assign it to the person who should be handling it.
Once an email message has been sucked into FogBugz, you can do all the usual FogBugz things like assign it, resolve it, etc., and you can do all the usual email functions, like reply to it, or forward it. FogBugz keeps track of everything, including the replies, right in the case. See this example screenshot.
When you reply to a message, FogBugz automatically inserts the case number into the subject line. That way, if your correspondent responds, FogBugz knows which case this belongs to, and inserts it in the appropriate case. The end result is that you have a nice record of the entire interaction right in FogBugz, even if multiple people have been responding from your side. If the FogBugz case is closed and your correspondent responds again, FogBugz just reopens the old case and appends the new message, rather than starting a new case.
To use this feature, you need an email server that supports the POP3 protocol. First, create the email account on your server if it doesn't already exist. Then, using the FogBugz Mailbox configuration screen, add a mailbox for this account. Provide all the POP3 log on information, and specify the details of where the new inquiry should go. You can enter a signature in the "Message Template" field, which will automatically be inserted at the top of any reply.
You can keep a permanent record of all email, if you have room in your FogBugz database. The Mailboxes screen also lets you set up a rule to permanently delete closed email messages after a certain amount of time. If a message is resolved as
SPAM, you may want to permanently delete it after a shorter interval, although it's a good idea to keep this at least 1 or 2 days so that if you accidentally resolve something as SPAM it won't instantly disappear.
Back to Top
Using FogBUGZ for Customer Bug Reports
FogBUGZ provides you with four ways to receive bug reports from customers.
First, you can create a mailbox to receive email submissions. For many customers this is the best way to handle it. You can then treat the submission as a bug: assign it to programmers, testers, etc., until it's fixed; when it's fixed, you can send an email back to the customer right from the bug.
Second, in the Projects screen, you can define any project as "allowing public submissions." As soon as you do this, anyone can go to your FogBUGZ web site (assuming it's on the public Internet) and enter new bugs in that project without logging on. Depending on how goofy your customers are, you may choose to create a holding-pen project for customer submissions and only move them into real projects when you've vetted them. If the customer includes their email when they fill out the bug submission form, you can correspond with them via email all within the FogBUGZ case.
Third, you can create web pages with any appearance you like on your own web page which redirect into the public submissions page of FogBUGZ.
Fourth, you can use our BugzScout ActiveX control or any http programming library to create code that enters bugs automatically. The ActiveX control is located in the Accessories folder of your FogBUGZ installation, along with ScoutSample.zip which contains sample Visual Basic code.
Back to Top
 FogBUGZ Home Page
Email: fogbugz@fogcreek.com | 
