Overview
Categories, Statuses, and Workflows are related to one another and help control how cases flow through FogBugz.
They are related to one another in that you define categories, then for each category, you define the statuses (these can be either Active or Resolved types), and finally, you set up the workflow defining how the statuses change can change the assignee upon transition to a new status.
You can modify any existing workflow, status or case, or create new ones.
Information
You can edit all three by clicking the Avatar Menu > Workflow.
Categories
There are four default Categories provided by FogBugz: Bug, Feature, Inquiry, and Schedule Item. You can add additional Categories by clicking the Avatar Menu > Workflow > Customize Categories.
Most users will probably find these four Categories sufficient for their needs, but you may end up wanting to add something like Feature Request with a set of Statuses that dictates the different stages it goes through (e.g. proposed, in-progress, rejected, postponed, etc).
Pro tip: you can upload custom icons for any category.
Statuses
Each category in FogBugz comes in two flavors, Active and Resolved.
By default, there is only one active status for each type of case, but if you need more active statuses, (for example Needing Replication) you can do so by clicking the Avatar Menu > Workflow > Customize Statuses.
Active: The first type of status for a case that usually means the case is ready for work or being worked on.
Resolved: A FogBugz user resolves a case when he/she decides that there is no more work left to do on the case.
Closed: The FogBugz user has decided that the case is sufficiently resolved.
Resolved statuses differ per category. A bug might be marked Resolved (Won’t Fix) whereas a feature might be resolved Resolved (Won’t Implement). There are also multiple resolve statuses per category, usually with one status that indicates the desired action (e.g. “Fixed”), with the other statuses indicating why the desired action didn’t take place (e.g. “Not Reproducible”, “Postponed”, etc.)
When working with other FogBugz users, usually the developer working on the case resolves the case. The person who reported the bug or requested the feature decides if the case can be closed, or reactivated.
When working with external customers or clients, usually a FogBugz user will Resolve & Close a case when responding to a customer or client. If the customer or client replies back, then the case will be reopened for further work. However, if the FogBugz user prefers to decide if a case can be closed at a later time, then simply and only resolve the case.
Note on Open and Closed: All Active cases are considered Open. A Resolved case can be either Open or Closed. More on that below.
Workflows
Workflows determine what happens when the status (based on category) changes for a given case within a project. You can edit workflows in FogBugz by going to clicking the Avatar Menu > Workflow > Customize Workflows.
While the statuses and categories apply globally for all projects, you can set up unique workflows for your projects.
Basic Workflow Example
The basic workflow of FogBugz is that cases are created in projects, assigned to the default assignee for that project, remain active until fixed, and then are resolved back to the person who reported the bug, who is then responsible for verifying its resolution and closing the case. Here’s how it looks played out in a FogBugz case:
Modifying the Default Workflow
The default workflow in FogBugz doesn’t always fit the workflow of software organizations, where you might want a QA person to test. For this, you can set the default assignee for, say, the Bug status of Resolved (Fixed) to someone in QA, while the default assignee for Resolved (Won’t Fix) should stay as the opener of the case.
In this example, Quentin is the QA lead, so he gets all cases that are Resolved (Fixed) so he can verify the fix. Here’s how this is reflected in FogBugz:
Note: The Force option simply means that the assignee cannot be changed in the same step as the resolution. In keeping with FogBugz’s general design principles, the assignee can be changed immediately after the forced step.