Change the Default Status When Moving between Issue Types

Question

We've setup workflows for Reports and Issues that are different. We use reports to quickly add things we need to look into further, but that are not ready for a developer to begin work on. In order to prevent duplicated reports and issues in the same sprint, we Move issues from reports to bug (issue types).

The move process tries to set the status to several steps further than it would if we were creating a new bug. Is the a way to set the default status when moving from one issue type to another?

Mister Hubbs · Answer

Reports come in from a number of sources. Those get assigned to a sprint based on their importance. Analysts work reports and developers work bugs. A report goes to an analyst. If the analyst deems the issue to need developer work, it is moved from a report to a bug. Reports are how new features are spec'd.  The process works fine, other than one small issue, which is when moving the issue from report to bug, its defaulting to the wrong status.

Derek Fields _RightStar_ · Answer

@Chris Hubbs This isn't a direct answer to your question, but why are you moving the issue type? In general, a process that requires you to Move issues from one type to another is an indication of a faulty process.

Having re-read your note a few times, I think that your first sentence should have be written:

We've setup workflows for Reports and Bugs that are different.

If that is correct, then what I understand is that a "Report" is some incident that may or may not require a developer to resolve. Until you have performed your root cause and know that the solution requires development, you don't want to schedule it into a Sprint. Once you do recognize it as a Bug, you move the Report to Bug and put it into the Sprint. If this is incorrect, then ignore the next paragraph and let me know where I misunderstood.

I would reconfigure your Bug process to allow all of the incidents to be Bug reports and get rid of the "Report" issue type. A Bug may not require any developer intervention. It may be resolved as "User Error" or "Feature, not Bug" or any number of other reasons that it didn't require scheduling into a Sprint. For those Bugs that are truly bugs and need developer resolution, they remain in the Backlog until the team pulls them into the appropriate Sprint. Then the team works them, just as they do today, until they are closed.

This has the advantage of a) treating all reports as potential bugs without having to worry about whether they are or not until you are ready; b) means you don't need a separate workflow; c) makes your metrics easier to follow.