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

New user confused by everything in Jira being an "issue". See description

Bob Blevins

I am used to projects being composed of tasks and tasks being made of changes to screens, reports, database changes, etc. In Jira everything is apparently an "issue". When I think of an issue, I think of "problem tickets" or "trouble tickets" which are often created by system users. Projects are how we address these trouble tickets (or issues). I find Jira's nomenclature confusing. Are there any good videos, books or other documentation which explain why Jira calls everything an "issue"?

Accepted answers

Norman Abramovitz

Nic is correct, it is just a label, but you are also projecting your understanding of what the word issue means. I did a google search for the definition of the word issue. The first defintiion that came up was

An important topic or problem for debate or discussion.

I think what people enter into their instance of Jira fits this definition very nicely.

All comments

Bob Blevins

By saying Jira calls everything an issue, I mean - Projects are collections of issues, components are subsets of projects and issues are (hopefully still) issues. So everything is either an issue or a collection of issues

Nic Brough -Adaptavist-

It really is just a label to mean "something that needs attention". You could call them a to-do item, an issue, an item, a ticket etc (although "ticket" is a dreadful cludge in English because it really doesn't mean what IT is trying to wedge it into meaning).

You can define whatever types of issue you think makes sense - bug, task, thingy, penguin - it's all just labels. That includes completely removing the type named "issue".

Karie Kelly1

It's always been a terminology problem in the companies I have implemented JIRA. The terminology of issues is negative and is indicative of a problem. We would prefer to have the option to implement our own term for it, such as Item, which has no positive or negative meaning or intonation. And then, you can have different item types.

But, agree, EVERY time I onboard a new company and a new user within a company, it is confusing and a problem.

We have asked for a property or system option to apply our own label - no luck.

Nic Brough -Adaptavist-

Yes. But it's not hard.

Nic Brough -Adaptavist-

Item is a far better word. Most of the places I've worked accept issue though, when talking about Jira, although most of them ask me to set up issue type schemes that don't include "issue" as it's too generic.

You can change it though - https://developer.atlassian.com/display/JIRADEV/Customizing+Text

Karie Kelly1

Nic, if you change it there, you have to make those changes with every upgrade, isn't that correct?

Norman Abramovitz

An important topic or problem for debate or discussion.

I think what people enter into their instance of Jira fits this definition very nicely.

Karie Kelly1

That is true. However, tasks, as an issue, are not problems for debate or discussion. An a type can be anything - whether it is, in our instance, an expense submittal or a move request - items that require workflow and authorization. Initially, it seems that JIRA was used for development projects to track development items like bugs, stories, epics, etc (but also tasks). However, we are not the only one that have broadened the use of JIRA as an ERP system for all of our departments - HR, management, ISO QA, customer projects, etc. And, have opened it for our customers to assist in tracking their projects.

When you consider JIRA as a means of tracking and managing anything requirement workflows, approvals, and/or assignments, then it can have value to others outside of just development. Thus, the terminology doesn't align well when you open it up to your customerbase and internal use for that expansion. And, in every one of my implementations, regardless, this is always a problem - thus, the reason for an option to modify that label. There are many applications where they allow you to apply your own terminology - this allows for easier adoption and understanding of the product. When this isn't allowed, then it becomes a distractor and something the admin or the sponsor (such as myself) must spend time on at all times (users change often due to turnover and new customesr). JIRA's ability to customize fields, attributs, statuses, steps to align with our own terminology is conducive to this. But, when a term like ISSUE appears everywhere, its the one last item to provide customers the flexibility to modify.

Nic Brough -Adaptavist-

I agree with Norman here - you're projecting your thoughts on to a label that Atlassian have chosen because it's pretty generic and reusable. I do think your suggestion of "item" is probably slightly better, but it does move away from the concept of Jira being an "Issue Tracker". It still suffers a similar problem in that it's generic and gives people the wrong idea. Most users are fine when you say "it's just a label to mean something we need to look at".

I really do think "issue" is already one of the best terms they could have chosen and it're really not that big an issue <cough>. None of the sites I've worked on has had a problem or asked for it to be changed (beyond not having "issue" as an issue type)

And, of course, you *can* change it if it's a massive problem for you. There's no easy interface for it, no, but there's no point in doing that for just one word that causes a minor problem for a small handful of users. If you're going to code for that, you need to do all the other concepts as well - project, components, versions, etc.

Norman Abramovitz

I think everything needs to discussed or thought about before it is done even if it is only for a fraction of a second.

Here is the first definition for the word, task, (as a noun)

A piece of work to be done or undertaken.

The problem I have with this word as my top level taxonomy is that it implies something must be done. Sometimes the solution is do nothing. It implies (yes, I am projecting here) a solution has been determined already.

I also agree that Atlassian should figure out how to allow users to make modifications without requiring redoing everything for each update. Changing the taxonomy should be one of those modifications. Now there is an issue that might be worth discussing! :>)

Don Carey_d85iip

You could call them a coconut if you wanted - to recount what Nic wrote, Issue comes from where Jira started, a trouble ticket application. And Nic also has a good suggestion to call it an item, which comes from the original description for a story which was a product backlog item (PBI) or story as in user story. I call them items, PBIs or stories. I don't call them Jiras as some folks do, because I have worked places that use other applications for managing the practice of scrum or kanban. I was taught scrum by the guy who is the co-creator and I learned the basic simple approach, because the framework is supposed to be simple. The practice is hard.

Max Bardus

Well, it isn't just that anymore. People in product and business department now use it.

Max Bardus

Yeah, Jira's UX Team need to look at their labeling. I see a lot of people are confused with it.

Welcome!

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

Quick Links

Find more posts tagged with

issue

jira