How are Projects and Areas used in FogBugz?
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 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. (In FogBugz every case is always assigned to one person, so that no case can fall through the cracks.)
If desired, you can also set up different primary contacts for each area.
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 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.
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, use tags. You can also group cases into hierarchies with subcases.
You can set a project to allow public submissions.
But if you set up one Project for every product you develop, how do you model releases of that product? Do they necessarily become just another Milestone in the project?
e.g. Milestones for Project "MyApp":
M1: some groundwork for v1.0 M2: a feature milestone for v1.0 M3: another feature milestone for v1.0 M4: final integration/hardening/system test for v1.0 M5: blackout for v1.0 M6: some groundwork for v2.0 ... [wash, rinse, repeat]
Is there a better way? It feels like a release should be able to be modeled such that its milestones can fade away and not clutter up later releases.