Categories, Statuses, and Workflows are related to one another and help control how cases flow through FogBugz. You can edit all three by clicking the gear icon > Workflow. Or, if you’re not using FogBugz Ocelot then click Admin > Workflow.
They are related to one another in that the types of categories you set up determine which statuses you have available. The categories and statuses together make up your workflow. Let’s take a deeper look.
There are four default Categories provided by FogBugz: Bug, Feature, Inquiry, and Schedule Item. You can add additional Categories by clicking the gear icon > Workflow > Customize Categories (or, if you’re not using FogBugz Ocelot then click Admin > 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.
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 gear icon > Workflow > Customize Statuses (or, if you’re not using FogBugz Ocelot then click Admin > 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.
A quick 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 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 gear icon > Workflow > Customize Workflows (or, if you’re not using FogBugz Ocelot then click Admin > Workflow > Customize Workflows).
While the statuses and categories apply globally for all projects, you can set up unique workflows for your projects. Let’s walk through an 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:
Another Example: 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 in the Workflow plug-in 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.
FogBugz workflow is simple by design. Two statuses, Active and Resolved, make up the basis for every workflow in FogBugz. If you’re getting started, we highly recommend starting simple and then adding complexity as you go along. It’s almost always better to start simply and add complexity organically as your use of the tool grows than to try to develop the perfect complex system out of the box. As always, if you have any questions, please feel free to contact us!