Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Naming Conventions for schemes

Hi there,

I am often thinking about naming conventions for all the schemes used in configuration.

Do you have any best practices for this. What are pro's and con's of your way naming the schemes?

Thanks a lot for your input.

1 comment

I do two things (well, three)

Naming by purpose 1: If a scheme is for a project, I use the project key as part of the name (usually the first part).  Jira now defaults to creating new schemes for projects with a similar pattern, so the lazy part of me tends to go along with that

Naming by purpose 2:  If a scheme is to be shared, I use a name that indicates what the shared purpose is.  If, for example, you have 5 ways of doing development, two support methods and one for project planning, I'd have 8 shared schemes, 5 saying "dev", 2 support and one planning

Versioning:  I'm not brilliant at remembering to do this, and when I fail, I'm bad at the grey area.  If you are making significant changes to a scheme, use version numbers.  Copy the current one and stick a 1.0 on the end of the name of the copy (or work on the master and use the copy as a backup).  If you're making smaller revisions, 1.1, 1.2, 1.3 etc.  Where I fail on the grey area bit is (especially in project schemes), if I feel the change is minor and unlikely to break other things, I don't back up and version.  "Make on field optional" or "hide field x".  I do when there's more than one change or more than one project affected.  You should refer to the version in your "Looking after Jira project in Jira, where people ask you to make changes".  Also, the lazy part of me works on the assumption that it's ok to have one non-versioned entry for a scheme, being the initially created one.  Version 0 = what you got off-the-shelf or the initial creation of it.

Note that whatever scheme you go for, Jira orders them alphabetically in the lists, so it's probably best to go with project-key or type of shared scheme first, as humans will find that a bit easier to follow (version numbers first in the name - no!)

The pros are traceability, and clarity in knowing what something is for, just by looking at it.

The cons are minor - it's a bit of a faff for your admins to remember to back everything up, there's room for error for your admins, and project-key changes can be a pain.

Hi @Nic Brough -Adaptavist-,

thanks for this detailed answer. 

I also used naming it by using the project key, and have it often seen in our customers instances, but what I learned is, when new projects are created, often the teams using them want to have it working like an existing project.

Renaming the schemes then is really a pain, so what we often see, is that it is shared, but the name still contains only the one project it was initially created for and that makes it often more confusing. 

Do you rename the schemes then or do you have other ideas to handle this.

Does Versioning really help you? There will be many unused scheme after a while. Or do you delete some of the old versioned schemes to clear this up? I could imagine, that this will be very confusing sometimes.

As soon as I think I'm going to start sharing a scheme, yes, I rename it, so it goes into the "shared purpose".  I dump the idea of trying to name the projects at that point, it's likely to be "development style X" or "team of people Y work this way"

Versioning does help in the short term, in case you make mistakes, or, more likely, the users found out the changes aren't quite right.  I always recommend it, but I'm also the type of admin who does house-keeping, which tends to involve deleting old versions, rarely keeping more than 3.

Thanks for that explanation. Maybe it helps if I can tell myy colleagues and customers that others also take that effort to rename schemes to have an environment they can handle well.

That way Versioning sounds good to me, I think I will try this out with my colleagues,


Log in or Sign up to comment