Projects

Setting up Projects

Each installation of FogBugz can be used to keep track of multiple projects. On typical software teams, you will set up a project for every individual product that you develop.

Within each project, you can divide cases into areas. For example, you might have separate areas for the Code and the Documentation of your project.

Any administrator can create and edit projects and areas by clicking on the Projects link in the top menu bar.

Each project has a primary contact. The primary contact is the person whom you've designated to look at cases and assign them to the appropriate person to fix. When someone enters a new case, they usually leave it assigned to the primary contact, the default. (In FogBugz every case is always assigned to one person, so that no case can fall through the cracks.)

If you are working on a large project team, you may want to have several people who help categorize new cases. To do this, we suggest that you set up a virtual user account called "Up For Grabs" and make Up For Grabs the owner of the project. You can use as many email addresses as you want for Up For Grabs, separated by commas, so that a group of people receive an email notification whenever there's a new bug in a particular project. Anyone who wants to help sort through new bugs can create a saved filter on "all cases assigned to Up For Grabs" which they check occasionally (or you can create this filter as a shared filter so that all users can see it).

Choosing Good Areas

In general you'll find that the fewer areas you have, the more likely people are to categorize cases correctly into the right area. Think of it this way: if you have 100 areas, everybody who enters a case is going to have to consider each of those 100 areas to decide which area is the best fit. Inevitably, cases will be miscategorized, and the pain of choosing an area may even make people enter fewer cases. If it's easier to jot down a case than enter it into FogBugz, you're going to lose the benefit of bug tracking.

The recommended approach is to start with just one area, called Miscellaneous, and use it for everything.

Then add areas only after careful consideration and only if they are needed for a particular filter that 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.

Public Projects

You can set a project to allow public submissions. Then someone who does not have a license, but can reach your FogBugz server, can come along, not log in, and click Enter a New Case. This is what they'll see: 

After submitting this case they are given a link that lets them view the current status of the case:

They can bookmark that link and come back at any time to view the status of that case. They will not see the comments that licensed users enter, only the status of the case.

When viewing the status of a particular case, they will be provided with links to view the statuses of all the other cases they've submitted.

If someone sends an email to a FogBugz mailbox, you can set it so that they will be sent a ticket number for their new case. They can then click "Check the status of a case" on the main FogBugz page and enter their ticket number. A ticket number contains random letters, so that people cannot guess other people's ticket numbers, and it allows the submitter to see all cases ever entered using their email address.