Naming Conventions for schemes

[Bastian Stehmann]

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.

[Nic Brough -Adaptavist-]

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.

[Bastian Stehmann]

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.

[Nic Brough -Adaptavist-]

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.

[Bastian Stehmann]

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,