Each installation of FogBugz can be used to keep track of multiple projects. On typical software teams, you might 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.
An administrator can create and edit projects and areas by clicking on Admin | Projects. Administrators can also determine which users can view, create and edit cases within a project with permissions
Each project has a primary contact. The primary contact is the default person whom you’ve designated to look at cases in this project and take the appropriate action (e.g. set their priority, assign them to the correct developer to fix, or send back to the opener requesting more information). When someone enters a new case, they usually leave it assigned to the primary contact. In FogBugz every case is always assigned to one person, which helps cases from falling through the cracks!
If desired, you can also set up different primary contacts for each area. By default, areas will inherit their primary contact from the project they are in.
If you are working on a large project team, you may want to have several people who help sort through new cases. To do this, we suggest that you set up a virtual user account called “Up For Grabs” and make that the primary contact of the project. You can use as many email addresses as you want for the Up For Grabs user, separated by commas, so that a group of people receive an email notification whenever there’s a new case 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.
Creating 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.
Our 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 absolutely need, because the more you have, the more likely cases will be misfiled. If you need finer categorization, you might consider using tags. You can also group cases into hierarchies with subcases.
You can set a project to allow public submissions.