Question

FogBugz 7 allows the addition of other categories of cases beyond bug, feature, inquiry, and schedule item.

We have a couple of examples of people adding new categories successfully, like "Risk" for risk management and "Technical Debt" for youthful transgressions.

What other categories might prove useful to add, given the new workflow functionality of FogBugz?

Answer 1

We are setting up several categories

1. Requirements

2. QA Item - schedule item for testers

3. Doc Item - schedule item for documentation

4. Customer Issue - for customer reported bugs, to be tracked differently from internal reported bugs

Answer 2

Task – simply because Schedule Items show up all together in the 'Working On' menu. I needed to separate the tasks I perform regularly (and hence want to quickly access to track my time) from one-time tasks that are not Features, Inquiries, or Bugs (I support our software too).

Answer 3

I can think of a ton of these if you use it as a complete product management tool and not just a developer tool.

Documentation - Used to task the technical writers. Really handy when opened as sub-cases under the bug or feature case.

Online help - Similar to documentation, but for updating in-app online help resources.

Graphic Design - For tasking the artists/UI guys.

Deployment - Any deployment related activities such as training, writing release notes or to send our IT guys instructions for deploying new versions of our web app. (arguably could be combined with Schedule Tasks, but we often want to track time for these separately)

Answer 4

Our company makes hardware and software and fogbugz is the closest thing we have to a product life cycle management tool(PLM). We are considering some categories for tracking case types that seem to be distinct to hardware projects or the specific phases of hardware development.

• NCMR non conforming material reporting to report when our manufacturer didn't compile our designs correctly into finished product. Similar to bug, but with different workflow requirement.
• ECO Engineering change order, essentially a feature, but the EE guys have always called them ECOs and the approval process may be different.

I would emphasize that although we are considering some of these, we are determined to first develop a threshold criteria that must be met before creating new fogbugz items.

Threshold criteria ideas:

• Case type needs a different workflow than existing types

• There are advantages to filtering this type of case away from existing case types.

• There are advantages to filtering for this type of case

Answer 5

We use 'Glitch', to differentiate bugs from design flaws, minor improvements and problems with very simple workarounds. It's a hard difference to make, though...

Answer 6

i feel we are stretching fogbugz a litte, as we use it mainly for project management but popular categories in our installation include:

• Job (for tracking job applications)
• Product (for ordering stuff and rudimentary inventory control -each thing in the office gets a case#)
• Project (for tracking the state of project contracts)
• Meeting (for setting agendas, jotting notes)
• Invoice (for tracking Invoices)

typical filters would include eg

• seeing all products with the state "waiting for delivery" when the postman arrives
• seeing all products with the state "available" when someone asks for a MIDI Interface
• seeing all job applications with state "resume complete but undecided"
• seeing invoices with state "overdue"
• seeing all jobs with state "offered (waiting foo client)"