New Status Type "in Development"

3 years ago
1 year ago


At the moment there are two statis "open" and "closed". For a better workflow it would be nice to have a new status called "in development" (or whatever).

That Status must also affect the roadmap. So that we do not only see the open and closed stati.

I think this new status would be helpful in the in the workflow of a development project. A projectleader for example can't see on the roadmap the correct status. Becouse "open" can be "open and nobody is taking care" or "there is already someone developing".

Even better would be if the admin can add as many parent statis as he likes. e.g. "open/new", "in developemtn", "testing", "closed"

Ticket History

3 years and 3 months ago by fadattf

of cource that is not type "defect". Should be "Feature".

3 years and 3 months ago by Jack

  • Changed Version from 3.6 to 4.0
  • Changed Type from Defect to Enhancement
  • Changed Status from New to Accepted
  • Assigned ticket to Jack

You've somehow read my mind.

I'm currently working on updating the Roadmap for 4.0 and was thinking instead of indicating open and closed issues on the progress bar, why not expand on it some more and have closed, started/in development and open.

I was thinking of having at least 3 mandatory statuses, New, Started and Closed, or having a way to indicate if the status is an open, started or closed type of status.

3 years and 2 months ago by Jamie R. McPeek

I think having the transition state is a good improvement. I would recommend for defaults rather than "Started", simply "In Progress".

I'll also second the idea of making this such that it's a state/categorization for each status type:

  • New (New)
  • Assigned (New)
  • Investigating (In Progress)
  • Fix Identified (In Progress)
  • Test Created (In Progress)
  • Completed (Closed)
  • Closed (Closed)
  • Won't Fix (Closed)

For tracking progress, we use a notion of Earned Value that would be easily applied here.

Assume that everything in the "New" state has no (0) earned value and that everything in the "Closed" state has full (1.0) earned value, then the project admin can apply any scaling to the "In Progress" states, for example:

  • Investigating (In Progress) 0.2
  • Fix Identified (In Progress) 0.7 -or- 0.5
  • Test Created (In Progress) 0.95 -or- 0.25

Whether you use absolute weights or relative (which prescribes a progression of internal states) doesn't really matter - probably whichever is easiest to implement and least confusing for the end user.

The final addition to this, then, is to add a new field to each ticket - an EV weight - which is simply a multiplier against the EV state. It should always default to 1.0 and be modified based on the amount of work relative to an "average" ticket.

These two notions combined will help to ensure you have a more accurate representation of not only the state of progress for any ticket itself, but also the overall progress towards the next milestone.

This also puts complete control on the project admin to determine what is right for their project rather than attempting to craft a one-size-fits-all system.

3 years and 2 months ago by Jamie R. McPeek

Addendum to the post above:

In my first example, I meant for this to be simply one option for status categories. The idea is to provide two key parts:

  1. Always have at least 1 of "New", "In Progress", and "Closed".
  2. Allow the categorization of "New", "In Progress", and "Closed" be applied to any status to allow the rest of the system to function.

2 years and 11 months ago by Jack

  • Changed Status from Accepted to Started

1 year and 9 months ago by Jack

  • Closed ticket as Completed