I don't have a problem with issue. But ticket is what all people are calling it on the ground. I try to unteach this term but people default to it regardless. Though they still understand the term issue.
Might as well give in to the masses and call it a ticket. It's generic and works with any product and doesn't interfere or confuse with standard "issue type" names. Please don't change it to task, will just cause massive confusion with issue type hierarchy explanation. I could easily adapt to Ticket Type Screen Scheme, Ticket Screen Scheme, Ticket screen. Ticket Filter Search. Otherwise, calling it "item" probably 2nd best option.
In saying that I think there are much more valuable and critical feature requests too invest time in over changing terminology that has such a wide-spread impact across Cloud and DC. I would personally pop this in the "nice to have" bucket. Is there a feature request for this? How many votes did it get that prompted you to develop?
@Denise Lydia Ellis I think relying on feature requests and votes might not be the best way to prioritize this.
The main goal, as I see it, is to make Jira easier to use for people outside of Development and IT, and to get more teams across the business on board. Those users aren’t really represented in the current requests or votes.
That’s the big downside of voting systems. They often miss out on the needs of untapped user groups.
Another big vote here for "ticket". It is easy to understand, doesn't overlap with any other terms and pairs well with the types; Story ticket, Task ticket, Bug ticket, Work ticket, even Epic ticket.
I usually refer to issues as "tickets" interchangeably but every person and organization might have a different term that resonates with them. I personally think that using a term that is very generic and ambiguous, such as "item", makes more sense. These are some of the reasons to think of it this way:
Multilanguage and translation. Jira is an international tool that is used in many different languages and choosing a specific term should take in consideration how this term is translated in other languages.
Jira configuration. The name should be unique in the Jira configuration so that when used to define types or type schemes, does not create more confusing. That is why I think "Task" is a bad idea as Task is already commonly used as one of the "types" in schemes (currently Issue Types and Issue Type Schemes).
Jira as tool to track what matters to you. There are many use cases for Jira where the tool is not used for ticket tracking. For instance, some people have used Jira to manage "assets" or "people". Using an ambiguous term will help with the adoption of a term for many more use cases than what Jira was traditionally designed for.
Having said all that, I believe the solution is not to replace one term with another. We can endlessly change terms and always find people in this world who will not find it appealing to them.
What about instead creating a solution that would allow the Jira Administrator to define the "atomic" term that will be used for each specific Jira site? That way the term will be perfect for each organization and meaningful to them.
I think that Item is too generic and Task as many have pointed out is already an issue type. I agree that Ticket is the way to go. Many of my users refer to Cards as their introduction to Jira was via Kanban boards but I don't think that is a good way to rename issues.
I still feel like we might be overreacting/overthinking this.
You'll still be able to create your own naming convention for the items you create (Incidents/Stories/Tasks/...) it's just in the general configuration that it changes..
Making it generic makes more sense then.
Trying to say it out loud makes it weird sometimes if for example it would be Ticket.
a Ticket of type Story or Story Ticket?
a Ticket of type Incident (that might work)
a Task Ticket..
In the end we'll still provide our own names for the things the users create
I see a lot of folks advocating for "Item", while I personally always liked "Ticket", I would definitely go for Item over Task or Work Item.
While y'all are at it, can you give all Items the same capabilities? The differentiation between level 1 vs level 0 vs level -1 is sooooooooo annoying.
It will be an adjustment for some of us old schoolers. But I do say that for general public and users it is a good move to help users understand the system better. Work Item can be translated easily and so can Task.
Here's to Jira moving forward to a new generation.
I always preferred 'Ticket', and the ticket type can be an 'Issue' if there is impact, a 'Task' to perform anything time bundled, and a 'Sub-task', for a smaller piece of the aforementioned type.
Tend to agree, "ticket" is colloquially what (for devs) we use to avoid the word "issue" in conversation. The problem is the nuance for other things, not all things are tickets. The tough reality is this really needs to be configurable by project. Internally, and at API level, they an call it just about anything, heck, call is a "jira" even, but call it within reason, just about anything other than an "issue."
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
I vote to keep it exactly as it is CURRENTLY. Also bear in mind that you then also have to TRANSLATE into the local language (Italian, Spanish, Danish, Polish, Chinese, Hindi, etc) and this may already cause further confusion among users.
@David VinsNow that I think about it, it's true that the main name could be "Jira". And we'll see which type it is hehehehehe. 'Please, open a Jira' is an expression I've heard a lot!
I dislike creating any functional distinction for work item vs. task. That does not solve any problem or need we have, and potentially causes a new one.
We already call stories/bugs/tasks/epics "items" and where that term is ambiguous, we just call these Jira items. The term "ticket" is sometimes used interchangeably, but we typically use that to refer to items in a Service (JSM) project.
Terminology changes can be a hard pill to swallow, especially when users are accustomed to what's currently being employed. I know it seems minor, but you'd be surprised how impactful small changes like this can be.
For example, as someone who works in an insurance industry related software company, I can tell you that there are a lot of old terms used in insurance that could do with a major overhaul, but simply haven't due to the impact from simple documentation through policies and even just human memory.
I'll be very interested to see how others react to this potential change.
While both "task" and "work item" are generic and good potential replacements, I have the following thoughts:
How about considering "ticket" as a third option?
Is there any possibility that users(admins) could choose the term they would like to use for each project? (As I am writing this, I see there are cases where this will be handy but at the same time can create confusions for other cases)
Could this field be a simple text box, allowing users to input any term they prefer?
For instance, within a single jira instance, I might want to use "issue" for bug tracking projects, "request" for service projects, and "task" for other types of projects.
Technical and business teams might also prefer using different terms depending on the type of project.
Not every task is an issue, not every issue is a ticket, and not every ticket is a request.
I am so happy to hear that Atlassian is looking to rename the term Issues; It's a real sticking point for some of our users 'cause they don't like the terminology as they feel it indicates that they are addressing issues, ie; problems or incidents (which this doesn't really work for them).
Like many before me, I would definitely vote for Ticket or Work Item as it is a pretty neutral name for a piece of work and is a wide enough descriptor to cover the various uses of Jira or JSM. Wouldn't be a fan of the re-use of the name Task as I feel this would cause confusion between the Task work type and the Task work item
Personally I don't think that a per-project setting for this makes sense. For example what would the "View all issues" menu be labeled if each project could define their own term? This is such a low level thing that in my opinion it needs to be a global setting.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
74 comments