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; } } }

Best practice for Project Key length

Karin Hicks

Hello - I was just on a call with a customer that wants a new project created. I let them know that the best practice was to limit it to 7 or less characters. He asked why? I didn't have a good answer for him than it was a best practice.

Is there any reason besides making it easier for someone to search for issues?

Accepted answers

Randy_dyxb6i

I think ease of use in conversation/referencing should be considered along with length.

e.g. ZXZW is harder to use than something like the longer key of ZOOMBA

where having shorter keys would help is when you view them in aggregate in reports or other pages and end up with the full key requiring you to scroll to see it in it's entirety. But that's only a concern if you are using and referencing them in those types of situations.

All comments

Randy_dyxb6i

I think ease of use in conversation/referencing should be considered along with length.

e.g. ZXZW is harder to use than something like the longer key of ZOOMBA

Karin Hicks

Thanks Randy!

Kirk Gould_ikub69

It is recommended that the key be as short as possible. It is not supposed to be descriptive, but rather recognizable and unique. The name and theme of the project can change over time. If the key is too well defined, it will point to the past and not the present. You will find that drop downs, releases, and sprints that are prefixed with the key become almost unusable when using 10 digit keys. The right side of almost everything is unseeable in multiple scenarios. Also, every time you are typing the name of an issue or a jql query that relies on a long, precise key, you will have to look it up and\or take longer. If you have a 3 letter key, you can make over 27,000 unique project key names. Hopefully that will be enough. I have seen it done long and short, and long helps in sub-optimized situations. Short helps most people in most situations.

Kirk Gould_ikub69

Examples:

TFGRWTHITM might Stand for "The First Growth Items.

TFGRWTHITT might stand for The First Growth Items Train.

Neither one is intuitive or guessable, but they are both descriptive and long. 1 Typo and they don't work.

GITM might also stand for Growth Items. You still might have to look key up, but it is quicker to type, takes up less room, is still a bit descriptive, and offers less opportunity for typos.

Kirk Gould_ikub69

It is recommended that the key be as short as possible. It is not supposed to be descriptive, but rather recognizable and unique. The name and theme of the project can change over time. If the key is too well defined and the purpose of the project changes along with the descriptive name, the key will point to the past and not the present.

You will find that drop downs, releases, and sprints that are prefixed with the key become almost unusable when using 10 digit keys. The right side of almost everything is unseeable in multiple scenarios. Also, every time you are typing the name of an issue or a jql query that relies on a long, precise key, you will have to look it up and\or take longer. If you have a 3 letter key, you can make over 27,000 unique project key names. Hopefully that will be enough. I have seen it done long and short, and long helps in sub-optimized situations. Short helps most people in most situations.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server