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

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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"?

6 answers

1 accepted

0 votes
Answer accepted

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.

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.

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.

Like Tom Hawkins likes this

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! :>)

@Norman Abramovitz although it might be "projecting" good amount of people are still confused with it. A good rule of thumb in design is to adapt technology to human mind rather than adapt humans to technology.

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.  

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

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

0 votes

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".

Yes. But it's not hard.

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

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.

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

0 votes

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 -

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you