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"
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.
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:
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:
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.
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:
Reopening this to implement in 3.x
of cource that is not type "defect". Should be "Feature".