Welcome to the FogBugz Knowledge Exchange

Question

2

I would like to set up a new workflow with the following steps 1. Specifications 2. code build 3. code initial test 4. code migration 5. code final test

Each step can have several status codes such as 1. Not started, in progress 2. Not started, in progress, requesting more specifications 3. Not Started, in progress, Completed 4. Not Started, in progress, Completed 5. Not Started, in progress, Completed, Moved to Production

Can you tell me how to set this up? I have installed the workflow plugin but am confused on how this would operate within Fogbugz.

flag	asked Jan 19 2010 at 17:45 Carl Myers 21●1

James McLeod · Answer 1 · 2010-01-20 16:06:01Z UTC

3

The simple answer is to create new categories for Specification, Code Build, Code Initial Test, Code Migration, and Code Final Test, and create the appropriate statuses for each.

I think, however, that the steps you have mentioned don't really correspond to a workflow in the FogBugz sense. I don't think it makes sense for a given case to start as a Specification, become a Code Build, move into a Code Initial Test, transform into a Code Migration, and end up as a Code Final Test. The specification should remain a specification, even after the code build has begun. Similarly for the other steps. I would make each one an area for the given project, and create a new case (cross-referenced to the previous ones) when moving to the next step.

answered Jan 20 2010 at 16:06

James McLeod♦
3,030●1●4●10

	Could you elaborate on this? I'm testing a seemingly complicated workflow: 1: developer FIXes, (automatically assigned to QA dept) 2: QA tests and marks as TESTED or REOPENED (bug not fixed) 3: QA marks VERIFIED 4: Release Manager marks RELEASED I'm having an issue in trying to make this work within the two-tiered active/resolved paradigm and I'm hitting a wall. any help? – jseminara Oct 27 2010 at 21:00
	@jseminara, I think your workflow matches FogBugz fairly well. I assume you've installed the Workflow plugin? 1. New cases are Active 2. Once coding and review are complete, cases become Active (Test) 3. After testing, cases are opened (back to original Active) or Resolved 4. Once case has been released, it is closed. You could also have separate cases for Resolved (Awaiting Release) and Resolved, but I think closing them on release simplifies things. The WorkFlow plugin will allow you to assign cases automatically on changing status. – James McLeod♦ Oct 27 2010 at 23:54
	Unfortunately, comments don't support formatting. If this is unreadable, make your question an official Question, and I'll put this as a (formatted) answer. – James McLeod♦ Oct 27 2010 at 23:55
	One more thought - you should do this anyway; it will let the community suggest which of several possible approaches is most credible... – James McLeod♦ Oct 27 2010 at 23:56

Rich Armstrong · Answer 2 · 2010-02-10 18:35:27Z UTC

The workflow plug-in is meant to support simple, two-step workflow, not multiple steps. To give an example, the use case of sending all resolved cases to a QA team for verification is well-supported. (Even if the support is kind of broad, in that you can't specify a reviewer for a given project, and should probably use a "Ready for QA Review" virtual user.)

More complex workflows, where something needs to go through multiple people, QA, original submitter, legal, etc, are not really allowed for in the workflow plug-in.

There's a reason for this. Arbitrarily complex workflow is very hard to do, and is very complicated to create and administer, so we shied away from supporting it with our workflow plug-in.

WorkFlow setup

2 Answers