#426 - New Status Type "in Development"
Type Enhancement
Status Completed
Milestone 3.8
Version -
Component -
Priority Normal
Severity Normal
Owner fadattf
Assigned to Jack
Reported 10 years ago
Updated 1 year ago
Votes 0
Related tickets
Proposed time
Worked time

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

10 years and 1 month ago by fadattf

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

10 years and 1 month ago by Jack

  • Version 3.6 4.0
  • Type Defect Enhancement
  • Status New Accepted
  • Assigned 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.

10 years 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.

10 years 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.

9 years and 8 months ago by Jack

  • Status Accepted Started
Jack closed as Completed 8 years and 7 months ago
Jack reopened as New 5 years and 1 month ago
Jack closed as Completed 4 years and 11 months ago

1 year and 11 months ago by Jack

  • Milestone 4.0 3.8
  • Version 4.0
  • Reopened ticket as Accepted

Reopening this to implement in 3.x

Jack closed as Completed 1 year and 11 months ago