Allow custom issue state
Allow an administrator to define custom issue states, instead of just the stock 'open' and 'closed' states. The administrator should then also be able to organise the milestone kanban-style view in such a way that the custom states can be a column.
Ideally we'd like to have a 'blocked' state, where progress on an issue is dependent on something else and therefore cannot continue to be worked on. Right now our only option for this is to use tags, but then tags can't be used in the milestone kanban-style view to indicate the actual active tasks and those that are blocked.
It would be really helpful for team's project management processes to have more state values for project issues. Here are some specific ideas:
* Include 'ready for review' as an issue state (in addition to open, closed and reopened),
* Add a 'priority' field with options like 'minor', 'normal', 'critical', 'major'
* Add 'category' field with options like 'Bug report' and 'feature'
Once we have this data attached to issues in predictable ways, we could take lots of other actions, like email notifications for critical issues, showing different categories of issues to different type of developers, etc. I think these kinds of features would go a long way making GitLab a great project management tool.
I realize this can be achieved by tagging, but issue label tags seem a little too.. free. Tags make it difficult to enforce structure and best practices. Having these values pre-defined in drop-down menus would make it dead simple to give more (important) details about a ticket.
Drupal.org has a pretty awesome bug tracker for example (see attached screenshot).
If folks think this is a good idea, I would volunteer to work on it.
The idea is not new and taken from Jira or eventum.
Each issues when created is set to status "opened". When someone starts working on it he set it's status to "In Progress" and all team know that someone (can maybe even know who) is working on it. In any time it can be "closed". When someone is done working on this issue and it's resolved, he sets status to "resolved". After that testers can test it and set status to "Closed".
Any Closed/Resolved task can be "Reopened".
Also can be helpful statuses as "On hold", "Released", "Evaluation", "Waiting for client/resources", etc.
Just checked out how GitHub handles issue states.
Looks like each issue can only be set as 'open' or 'closed,' but you can customize fixed 'Labels' that describe the current 'open' or 'closed' state.
This might be a useful middle ground that's more structured than 'tags' but not destructive to the existing 'open' or 'closed' nature of tickets.
Upvote for this feature, we often need to validate the issue as "fixed but needs to be tested/validate"
Posted a similar issue the other day, somehow I missed this ticket looking for something similar http://feedback.gitlab.com/forums/176466-general/suggestions/5083989-more-comprehensive-issue-states-and-status-paramet
Here's a few thoughts -
Is it worth making these options user-defined given that most workflows are pretty similar most of the time? Should we just decide on a few ticket states that's most useful for everyone and hard-code those into the database? Or is there something essential about having them be customizable?
Also, are these 'states' in themselves, or are they providing metadata about a ticket's opened or closed state? In other words, can a ticket be 'open' AND 'blocked' or is it just 'blocked'? Or is a ticket 'closed' because it's a 'duplicate'? In terms of implementation, I'm trying to understand if these are additional issue states (as in Issue#state in the codebase) or if they are an additional field on the Issue model.
AdminGitLab team (Admin, Gitlab) commented
Jason, thanks for the idea and the screenshot. This request seems to be two things in one. I think the issue state is already in http://feedback.gitlab.com/forums/176466-general/suggestions/4283809-allow-custom-issue-state and having multiple customizable categories is a new one. Do you want me to merge the into the other one or edit it to be about adding multiple customizable categories?
Alexander Polyanskikh commented
Something similar but more generic was suggested earlier in http://feedback.gitlab.com/forums/176466-general/suggestions/4283809-allow-custom-issue-state
Other possible state:
* Won't fix
Bjørn Otto Vasbotten commented
This is a great idea.
Mathew Winstone commented
This is an important issue (pun intended ;-)
Dealing with workflow and tracking status of issues is tough when the only options are open/closed.
Tags can help but the tag system isn't robust enough to make it a viable long term solution.
There was an issue about that but they closed it :-(