Fog Creek Software
Discussion Board




Workflow

It would good if one could do work flow e.g. have product Manager (defining priorities (which version/patch it should appear in), closing issues etc), they would pass it on a support manager to delegate to thier staff to validate and resolve (if resolved it would be go back via the support manager to the product manager, they do not do bug fixes) or pass on to the development manager who would delegrate it to testers and developers. A bug should not be marked as resolved unless the code changes have been tested. Then it will go back via the development manager to the support manager (who may need to install it on site to finally resolve the issue) and then finally to the Product manager who will close the issue.

Hannes van Wyk
Tuesday, February 19, 2002

Actually our method is that a bug can be marked as "resolved" as soon as the developer thinks it is fixed, but it should not be CLOSED until QA has confirmed it.

The FogBUGZ philosphy is not to "hard-code" workflow but rather to trust people to understand what to do. The trouble with hard-coded workflow is that when it doesn't make sense for a particular application, it just gets in the way.

For example, many developers using FogBUGZ make "bugs" for their own personal to-do lists. These items obviously do not have to go through QA, management, and all kinds of bureaucratic sign-offs. If FogBUGZ were set up to enforce workflow, developers could not use FogBUGZ for their personal to-do lists which would reduces its value.

What we do instead is "lightweight" workflow, where, basically, the *default* assignee is "the right person" but you can change it or override it if that makes sense.

Joel Spolsky
Friday, February 22, 2002

*  Recent Topics

*  Fog Creek Home