Statuses and Transitions

[Thomas Fitzgerald]

Statuses and transitions are shared between each project and workflow.

Currently, our status is shared on over 90 different workflows.

However as there are different projects within these workflows, they have different requirements, how does anyone else deal with this?

Instead of adding a large prefix such as "Project-Dragonboat Ready for QA"

How do other instances have this setup? I am trying to create the best JIRA instance for our developers however with the names very similar, one project requests a change, then another project requests the change back.

I cannot find best practises etc for this, so thought the online community may be able to help me with this 

Any thoughts?

[Michael Wohlgemuth (Wolge)]

Take all of the following with a grain of salt. Im not very experienced yet myself:

There is no need for a "Project-Dragonboat Ready for QA" as well as a "Project-Butterfly Ready for QA"status. "Ready for QA" is enough for both usually. If you want to restrict reports and such you can use JQL to specify the project later.

If, on the other hand, Project-Butterfly needs a "Ready for Flying" status, and Project-Dragonboat needs a "Ready for Rowing" status, then you would have to associate 2 different workflows with the 2 projects (and create/use the respective status in there).

I beg anyone with more experience to chime in here, because im a noob myself with oh so much to learn still.

[Thomas Fitzgerald]

Thank you for the message Michael, I am in a similar situation as I am new to JIRA myself, I am aware we can share statuses and transitions but I believe I need to move away from shared statuses due to what I mention in the below paragraphs, currently, we have 3 or 4 statuses ("Done" for example) which is shared among 100 workflows, "Ready for QA" shared among 80-90 odd workflows.

We don't have any Change management for JIRA. 

Currently, I am the only person administering JIRA, due to workflows sharing all these statuses, we get some developers requesting changes to workflows, or new projects starting with specific requirements and we implement these changes, adding specific validators for that new project into their statuses and transitions.

A few days/hours later several developers log angry tickets that we changed their workflows, however, we did not change them intentionally, we find out afterwards that they are shared.

I have picked up a half-baked JIRA and been told to manage/administer it. Before I continue I would like to find out the best way forward, this is the idea behind this discussion, I would like to encourage anyone with little or a lot to continue this discussion!

[Michael Wohlgemuth (Wolge)]

adding specific validators for that new project into their statuses and transitions

If this is the requirements for a new project or change to an existing one, then it cannot and should not be done with a shared workflow since, as you already discovered, this has effects on all the projects that use this workflow.

You have to create a new one for this project in this case.

the best way forward

My two cents: Leave the old workflow as it is. Keep using this one (if there are no problems with it) for projects that work well with the already shared workflow. Then create another workflow for the project that needs special conditions/validators/statuses so you can satisfy their needs and associate it with that project. By doing that, you can add statuses, conditions, validators, post functions and whatever more you want without having any effect on the workflow that is currently shared between many projects.

[EDIT]

This may be a lot of work, depending on how many projects with unique requirements you have. I do not think that there is a way around that.