FogBugz Technical Support

A forum for technical support discussion related to Fogbugz.
The current FogBugz Knowledge Base can be found at

Posts by Fog Creek Employees are marked:

Release Notes
Network Status

Any way to organize or group cases?

I work at a relatively large company with well over 200 engineers.  Last year we shipped over 60 new products.  We have over a dozen support applications under constant development. 

I am very intrigued by the EBS system and the core concepts of being easy a fast to use.  However, I feel like our company would need some additional ways of organizing cases.

The idea of keeping a list of very small detailed items which can be easily estimated makes a lot of sense.  But say for just one of our support applications, we have a dozen new features for the next release, each being very complicated and thus have a list of tasks of a dozen items or more.  Let alone the years of minor enhancement requests and bugs which may be insignificant to new product support.  So if we have a list of 300+ items (in reality my specific app has over 1500 open items in our Bugzilla database), a flat list doesn't seem adequate.  Say 12 new features each with 12 tasks, mixing them up in a flat list of 144 items seems like a problem.

Are there ways to accomplish this that may not be explicit in the interface?  Am I missing something?
William LeVine Send private email
Thursday, October 30, 2008
The way that our company has overcome this is by using the narrowest Project/Area/"Fix For" that we can for each item.
This allows each user to look at their items in many ways.  They can look at their full list, filter the list for a specific release (Fix For), view all of the cases on a specific Project, or filter for a specific Area of the site (business logic, templates, etc).  This can be done as a search for cases only assigned to them, or to the entire team.
Jack M. Send private email
Thursday, October 30, 2008
We accomplish this with project areas and fix-fors.  We have a FogBugz project with multiple areas.  Drilling down to area and fixfor is enough for us.  For features, we always work from a spec.  Those happen in the wiki, and are boiled down to cases.
Rich Armstrong Send private email
Thursday, November 6, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz Bug Tracking and Evidence-Based Scheduling.