I frequently work with teams who want to expand their use of Jira beyond the dev people. Are these non-pure-dev scenarios why 'None' is so contagious in my projects? Or is it something else? I am not sure, but this is what happens:
We define a custom field with a single or multi select option. For example:
Field name: 'Customer impact'
Options:
No impact
Downtime
Change in functionality
So far, it is simple.
Now, when the field value is not set, assuming we opt to see the field when it's empty, Jira will show the value as 'None'.
But what does 'Customer impact = None' actually mean?
You see the problem. Someone who is not a Jira aficionado will think that there is no Customer Impact. Which is not correct.
So, to circumvent this, people want to set a default value 'Not evaluated' instead of leaving this empty.
The next thing is that we need to condition and validate at different transitions that the field is set. Which becomes much more complex because the system always sets the field to its default value instead of leaving it empty. Creating a more complex configuration then what we could have had.
Have you run into these contemplations? How do you weight the tradeoff and what do you eventually do in these scenarios?
Edit 18-Jan-2025
If you are finding this issue frustrating please vote on this JRACLOUD issue: https://jira.atlassian.com/browse/JRACLOUD-7320
Unbelievably this is an issue from 2005. At the moment, it does not have ton of votes, so- please vote this up. Perhaps we can make change happen
I've encountered this problem many times over the years and have tried all the things you described.
So far, my preferred (least bad 😆) solution is to validate the field on workflow transitions without setting a default value first. That keeps the workflow logic a little cleaner, and the problem of 'Customer Impact = None' (for example) is short-lived until the issue is transitioned.
That said, I've long wished that Jira would display something like 'Empty' or 'No value' instead of 'None'.
When I've run into this my stance has so far been that, if a field has a value it has been set actively, and someone has had a look at the Issue and with an active opinion or knowledge decided that the field value should be set to whatever it's set as.
So if Customer Impact was set to None, I would expect that someone with knowledge, an opinion, and mandate, has actively set it based on the content of the Issue, and as such decided that there is no customer impact.
I have been explaining to the user(s) this, and that how when a field does not have a value it is "Customer Impact" IS EMPTY rather than "Customer Impact" = None.
I would also argue against using "Not evaluated" as an analogy for the field not having a value set.
Sure, it can be done, and you can work around it with your situation of Workflow conditions or validations, but it's really a slippery slope and adds undue complexity that could have been avoided if the users had a better knowledge or understanding of JQL.
Also, pr. my stance on "if it has a value it was intentional" then the field being empty means the same as it having the value of Not evaluated, making it duplicate and unnecessary.
And with all that, it would be nice if the descriptive grayed out text wasn't the word "None", but something else like "Empty" or "No value", like @Aaron Morris mentioned, or maybe even just not have a text.
Maybe just have a outline around the field to indicate that there is a field here and it has no current value.
It is a familiar topic that I have had endless discussions about throughout the years.
My suggestion would be to first create a suggestion with Atlassian, to do as mentioned in some of the replies to your post: ask to change the text to something other than "None".
Atlassian being on the verge of renaming "Issue" to "Work" (another one of those hot topics over the years), they may as well address this topic as well!
Your current solution, with a default value set seems most used in environments I worked, but can give challenges down the road, like the ones you described and with reporting, but it is my personal preference of the available options, because it is the least problematic for cases where people mistake the non-value for "None" value ;)
Educating people, creating clear documentation for the project and adding a description to the field are things that can help avoid mistakes with it.
@Michiel Schuijer
I did as you suggested and raise a support ticket with Atlassian. Once there is an issue key I'll share so we can vote.
Thanks for suggesting
@Dave Meredith @Rune Rasmussen @Michiel Schuijer @Aaron Morris
Atlassian support found an existing issue on this (from 2005!!).
Please vote on this JRACLOUD issue: https://jira.atlassian.com/browse/JRACLOUD-7320
At the moment, it does not have ton of votes, so- please vote this up and ask your friend too. Perhaps we can make change happen
Hey @Rina Nir
Thank you for sharing your use case and feedback!
I’m a product manager for the Issue View and have the "none" values on my radar. I’d love to connect and discuss further. If you’re open to a call, please feel free to schedule a time that works for you through my Calendly link.
Looking forward to hearing from you!
Thanks Ahmud
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Become an effective Jira admin
Manage global settings and shared configurations called schemes to achieve goals more quickly.
Streamline Jira administration with effective governance
Improve how you administer and maintain Jira and minimize clutter for users and administrators.
Learning Path
Become an effective Jira software project admin
Set up software projects and configure tools and agile boards to meet your team's needs.