The current Project Categories functionality is way too broad of a feature. It completely overlooks those using modified agile workflows or non-agile workflow such as in JIRA Core. Also, it fails to handle the possibility that a single status could be used in 2 different projects at 2 completely different locations in a workflow. Not to mention that it could possibly be used as 2 separate purposes within the same project in 2 different workflows on 2 different issue types. The possibility that the same status is used as a ending state (done) and an In Progress state in the same project is very slim, but i've actually seen it before.

For example, I have seen a status called "Verified" which in one workflow was used as the final complete state (Done). However, on a different issue type in the same project it was used as a middle state in the workflow where "Closed" was used as the Done state. Now, on the global Status level, which category do you assign to the "Verified" state?

Another example is when a single workflow transitions an issue to multiple different job roles. Therefore, based on the state of the workflow it may be in person1's queue and they have their own To Do, In Progress, Done statuses, but when it is in Done for person1, then it moves to person2's To Do queue where they also have their own In Progress and Done states. However, with the global category setting, it turns out that both person1's and person2's statuses all end up being "In Progress" and therefore are all colored yellow. Have you ever seen a dashboard with this new category system in this use case? Every single status on the entire dashboard is yellow. How is that beneficial to the user?

The current implementation also falls short on the UI of the statuses, Please return these status names in the UI to Camel Case because all caps is harder to read. Human eyes are conditioned to read characters in Camel Case and therefore these words are easier to identify at a single glance. ALL CAPS ARE TOUGH TO READ BECAUSE EACH CHARACTER IS THE SAME HEIGHT AND THEREFORE THE BRAIN NEEDS TO READ EACH CHARACTER SEPARATELY IN ORDER TO DETERMINE THE WORDS. This is just something that will allow users to be able to quickly identify the status by name since the vast majority, if not all, statuses will be in a yellow state.

With the Categories, you have gone backwards in the ability to quickly identify a status and it's meaning.

On other issues it has been mentioned that the new categories was put in place in order to assist with the new Project Release board which shows the current fix version and a "pretty" blue, yellow, green bar to show the progress of that version. Since this seems to be the only reason to implement project categories, it just doesn't make sense to do so on the global level. For the same reasons as above, the project categories could be incorrectly colored for one project, but be correct for another. Therefore, the Release board is only useful for 1 of those 2 projects. Therefore, if you want to keep the Release board around, you should shift the category assignments to statuses down to at least the project level if not the project/issue type level.

In summary, the status categories need to be removed or altered to better suit ALL possible uses of JIRA. Atlassian is making a big push with JIRA Core, JIRA Software, and JIRA Service Desk to make JIRA appealing to all different types of uses, but this functionality goes against that drive and actually hinders it. Please make a change.