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.

[Nic Brough -Adaptavist- · Accepted solution]

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

[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..

[Nic Brough -Adaptavist-]

I don't think you need to consolidate all your projects into one? The field will work across all issues if you want.

[Eric Pili]

Not to take us 2 steps back on the conversation (and you may have been hinting to it in your previous response), but I just realize through playing around that the "Components" and "Versions" fields do exactly what i am looking for by utlizing something called an "Auto Complete Renderer".

I don't see a way to attach that "renderer" to one of my custom fields. But until that gets added, i can just use one of those fields to accomplish what i need since i don't need them for anything else.

Is there any down side to using those?

[Nic Brough -Adaptavist-]

Yes, that's what I meant by the auto-complete for those fields - the renderer for them is doing the work. It's annoying that components is effectively nothing more than a multi-select (when it's on-screen anyway), and it has that renderer while the custom field does not.

The downside of using components to do this is that they are project specfic. So if you want a component of "penguins", you have to add it to ALL the projects, and when you run a search, even if you've used the same name, you will be searching for multiple objects. Penguins in Project A is not the same as Penguins in Project B

(I wouldn't use versions at all - totally different functionality lives behind them)

[Eric Pili]

While not ideal, them being project specific might not be a deal breaker. I was thinking of grouping all of our internal projects into a single (or small few) "Jira" projects anyway, so it could be managable.

I can use KANBAN boards accross projects, so that is a wash. Reporting is cross project, this could complicate queries, but again not the end of the world as ours will likely be pretty static anyway.

The real disadvantage is that I would loose the heatmap and other label specific functionlity, but i still can find the issues by using the Component filter pretty easily. That would be trade off for getting the auto-complete.

I will set up both scenarios and see what plays out better. Thanks again for all the info. I might hit you up again tommorrow with some additional questions.