nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Using Labels Instead of Projects

Eric Pili

I am new to Jira to bear with me on this. I am trying to figure out the best way to organize the projects for our development team in Jira. At any given time we have about 50+ active projects going cycling between about 8 developers. New requirements are added daily, with a turnaround time of anywhere from a day to a week. Initially when I looked at Jira I was thinking that I would create a separate project for each, and then group the projects into 6 Project Categories. (Intranet sites, Client Programs, Console Apps, etc…)

I recently ran across a video about “Jira labels” and I am thinking that there might be a better way. Instead of having 50 separate projects in 6 different project categories, I could just create 6 projects. (one for each category). And use the labels to distinguish between the actual projects. That seems like it will work and have the advantage of being able to cross associate an issue to multiple projects if it touches more than 1. (which does happen)

So along those lines I was looking for some advice around Jira labels and their usage.

1. Can I set up Jira to require a value in the label field?

2. Can I predefine the possible labels values that my developers would have to choose from?

3. Can I report and search based on those labels?

4. I read somewhere that said I can create custom fields of type “label”. Is there a benefit to that over using the build in one?

Also, if you have a better solution for what I am trying to accomplish or any general advice about labels, I am all ears..

Thanks in advance for any help you can give.

Accepted answers

Nic Brough -Adaptavist-

Ok, to start with the question list.

1. Not easily, you need a bit of advanced config to do this

2. No. The whole point of the field type is that labels are free-format labels to arbitrarily group issues together.

3. Yes, absolutely

4. You can create many custom fields of any type. Labels is a type and there's a single one by default, but you could add another called "area", and another for "colour" and another for ...

... Now, to aim for a solution, you could very easily fix 1 and 2 by simply defining a globally used "multi-select list" field instead of a label. The list of options is set by administrators and you can use field configurations to force users to enter it. Answer 3 remains the same, then 4 is still a "yes" because you can add as many of these as you want as well.

One additional trick I've used - if you implement it as above, you could continue to use labels alongside it too, allowing users to enter their own labels. Educate them that they're free to use them for anything they want to, but especially if they aren't sure about the content of your multi-select options. Then, as a good admin, you monitor the use of labels (heatmap gadget is rather handy) and if you spot the users consistently raising very similar labels, ask them if they're a candidate to add to the multi-select

All comments

Nic Brough -Adaptavist-

Ok, to start with the question list.

1. Not easily, you need a bit of advanced config to do this

2. No. The whole point of the field type is that labels are free-format labels to arbitrarily group issues together.

3. Yes, absolutely

4. You can create many custom fields of any type. Labels is a type and there's a single one by default, but you could add another called "area", and another for "colour" and another for ...

Eric Pili

Thanks for all the advice Nic. After combing through your suggestions a few times and playing I think I understand your suggestion. And I agree it is likely a better solution. There is 1 hurdle that I was hoping you can help me work out. I REALLY like the UI interface for entering the labels vs using the multi-select box. Since that box will have 50+ selectable items in there, it seems like it would get a little unruly having my developer sift through all the possible choices (holding the control key and using the mouse). Whereas the “Label” field acts more like a text box with an autocomplete.

Are there any hybrid custom field types that give the functionality of the multi-select with the usability of the label?

Nic Brough -Adaptavist-

Mmm, I'm still hoping to get the labels/components/versions type-ahead implemented for multi-select fields. That would solve it, but it's not there yet.

Eric Pili

OK, so knowing that isn't possible i think i am going to take your suggestion. Hear me out and let me know if you see any downfalls to the following...

I am going to consolidate all of our projects under 1 Jira Project.

To that I will add a "Cascading Select List" Custom Field called "Main Project". I will make that required and the users will have to pick atleast 1 when creating an issue. That will ensure that every issue is related to atleast 1 "Main Project"

Then, as you suggested, i will create another customer field called "Tags" that is of Label type. The users can use that field to add other projects/topics that the issue could related too. I will also make this fields required so they have to enter atleast 1.

Do you see any down side to that approach. And thanks again for all the help with getting this worked out..