Good Morning, Jira Guys and Gals! I hope you had an enjoyable (and, most importantly, restful) holiday season and are entering 2024 strong! I know I am – I have so many plans for this blog, The Jira Life, and my social media profiles that if everything works out, 2024 will be amazing.

Speaking of amazing times, I got an email from one of you on my birthday. While I always appreciate emails from fans – I especially love ones that give me a topic to write about!

The reader wanted to know my thoughts on naming conventions of objects – how to go about naming the various schemes and settings in Jira so that you can find related elements, help admins find relevant settings fast, and prevent mistakes or duplicates.  

Don’t get me wrong, I read this and instantly had opinions. I have standard practices I’ve been using forever. However, when I went to see if there was any official literature on the topic, I found nothing from Atlassian.  

So I went to the next best source – the Community Leaders of the Atlassian Community. These are the most prolific answerers of questions on the Community Site – so if anyone had some good advice, it’d be these people. And they didn’t disappoint with many thoughts, experiences, and tips. So, let’s dive into this topic and see how we should be naming things!

Rule 1: Traceability

So, what is the first question we want answered when we look at an object? Simply put, this should be, “Where does this object fit into my configuration?” Is this a workflow belonging to the bug issue type of Project XYZ? Or is it a Creation screen for the stories of Project ABC?  

Jira gives us a couple of answers right off the bat. We can (usually) see what project an object belongs to, the schemes the object is attached to, and the last time it was updated.  

But that is usually only part of the answer. The default object and scheme names leave a lot to be desired. However, the object name is a freeform text field, so I like to use this to get more information.

My object names almost invariably end up taking this format:

[Project Key] – <issue type> <detail> <Object type>

So, let’s take Project ABC, which has the issue types Story, Bug, Task, and Subtasks.

My workflow (and their scheme) scheme would be:

• [ABC] Workflow Scheme
  • [ABC] Story Workflow
  • [ABC] Bug Workflow
  • [ABC] Task Subtask Workflow

My Screen setup would be:

• [ABC] Issue Type Screen Scheme
  • [ABC] Story Screen Scheme
    • [ABC] Story Create Screen
    • [ABC] Story Edit View Screen
  • [ABC] Bug Screen Scheme
    • [ABC] Bug Create Edit View Screen
  • [Standard] Task Subtask Screen Scheme
    • [Standard] Task Subtask Create Edit Screen
    • [Standard] Task Subtask View Screen

Permission Schemes

• Default Permission Scheme

Now – I want to note something here. You should only configure it to the point where it makes sense. If a default or existing configuration works, don’t be afraid to reuse it.  

But if you are reusing schemes or objects, update the object name to denote the new dependency. Likewise, if you have a scheme or object you are setting up as an Org Standard, label those appropriately, too.  

This practice addresses the second question you should try to answer when looking at an object: “What could I mess up by editing this thing?” I have gotten too many calls from people who modified something with multiple dependencies, causing other projects to break. This cannot be fixed entirely – some people only learn the hard way – but you can at least limit how often this happens by labeling things better.  

Rule 2: Limit your Version Control

Any good Admin should follow this one rule about changes: Make sure you have a way to revert any change you make quickly. In Jira, this usually takes the form of making an inactive backup of an object before making a change. If something goes wrong, you can always revert to the old copy; no harm, no foul.  

And yes, this is a great best practice and something everyone should be doing. But what invariably happens? You get one or two weeks past the change, and you’re not thinking about that anymore. You’re onto the next project and the next change and that backup object is still sitting there. As are the other four copies from other changes. And the other 96 change backups from other objects and other projects. These objects are inactive, so they are not doing anyone any good, but they are still taking up resources, and with enough of them, slowing down your instance. Yes, in a perfect world, we would all go back and clean these up. But we don’t live in a perfect world – I am very guilty of this practice!

So why bring this up in a post about naming conventions? Ideally, we should use the object names to help denote three things.

• First: This thing is a backup
• Second: The date this backup was taken
• Third: The date after which this backup can be safely deleted.

As such, I’d recommend your backup objects take the following format:

Backup: [Project Key] – <issue type> <detail> <Object type> Taken: <date> Expires: <future date>

That way, when you are doing your quarterly cleanup – or you happen to find yourself in the inactive section of your workflows or schemes – you can delete all those that have expired. 

Rule 3: Cleanup is a regular activity, not a one-time thing

So you go through all your schemes and objects, ensure they match your designated format, and everything is tidy. Then Life happens. You have 13 requests affecting 28 different projects, all screaming that they needed whatever a month ago despite only putting the ticket in yesterday. This scenario happens repeatedly for a few months, and suddenly your schemes look like no one has ever touched them.

And to be fair, for a few months, no one has. Life happens, even to the best Jira Admins, so don’t be too hard on yourself. But this gets to my next point: Cleanup should be a regular activity. You don’t clean up your house once and expect it to stay that way (Jira Guys and Gals that are also parents, am I wrong?). The same is true for your Jira instances.  

You should set aside time regularly to reclean your objects, clean out your inactive backups, and set things in order. Ideally, I would like to target at least once every quarter, but as I said above, Life Happens, so sometimes clean up is a “when I have time” activity. But you can’t expect things to stay in order – remember, your primary job as a Jira Admin is to fight Entropy, and Entropy is always happening. 

Rule 4: The Rules are more like suggestions, really. 

Don’t get me wrong, I stand by what I’ve written, but I’m not foolhardy enough to believe they will cover every situation. While I believe this would work for most organizations, it won’t be universal, and you might just find yourself in a situation I haven’t covered.  

For example, what do you do if you have a screen not associated with a project but a workflow step? (Yes, I intentionally left this out for this example :P)

So what do you do? You do your best! For me, I’d probably name the above example <workflow name> <transition name> Screen, 

So this would look like “[ABC] Story Workflow Approval Screen,” as an example.  

But as I said, that’s my best guess. Part of what makes a good Jira Admin is taking incomplete information – be that a request or a set of rules – and extrapolating the missing information to cover the situation.  

What do you think?

What are some of your rules and naming conventions within Jira? Do you have any? I want to hear from you.  

This post officially marks my first of 2024. Last year was…interesting. While it was an amazing year with the founding of the #AtlassianCreators Program and The Jira Life, it was also a year I battled executive dysfunction a lot – which is more than evident in my posting record last year.  

But I also took a stand for the blog when my day job tried to make me decide between being “The Jira Guy” and it. That is still scary, but I’m making it with the support of some big friends in the Atlassian Ecosystem. I’m optimistic about 2024 as I continue learning and honing my social media skillset and collaborating with some amazing content creators.

Speaking of Collabs, don’t forget that tomorrow and every Thursday, I cohost a podcast with Alex of Aptech Tech Tutorials we call “The Jira Life.”

We have just kicked off Season 2 with 2024, and our buzzword is “professionalism.” So check out the channel trailer and subscribe if you haven’t. Because we didn’t choose The Jira Life, The Jira Life chose us!

I am also starting on my Team ’24 prep for this year. So far, yes, I will be there, as will Alex. We are still in the early days of planning #AtlassianCreator events, collabs, and whatnot. But I already have the first drafts of the 2024 TJG sticker designed, and I’m so excited about some of the talks I’ve had!

But until next time, my name is Rodney, asking, “Have you updated your Jira Issues today?”