First off, let's definitely applaud that Atlassian after 20+ years is finally cleaning up vestigial leftovers from being just a bug tracker, I think this "work" is still better than "Issue" which can be synonymous with "problem" (which is clear from its origins that was the intent). And "Task" would not have been great since task is a common / default issue type and Epics are not tasks they're collections of tasks.
I think everyone also needs to acknowledge that Atlassian is a business and there is no business value to making this change at all, unless....
...unless they can use it as a marketing strategy, which if you read the new blog post: https://www.atlassian.com/blog/jira/work-your-way it is very clear that "Work" or "Work Item" is marketable for them following on the heels of merging Jira Work Management & Jira Software.
Also, Josh pretty much confirms it by saying they're trying to appeal to new users (marketing).
I know that many of you have been navigating 'issue' terminology for years. However, our research indicates that these challenges are more acutely felt by newer usersand those outside of product or software teams. We reviewed many of the alternative terms mentioned above, but they were often found to be too technical or ambiguous.
Let's just be thankful for a small improvement and go on colloquially calling it whatever we want.
On that topic, no one suggesting letting this back end term be admin configurable could have possibly thought through the ramifications of what they are suggesting and the headache that would ensue from doing something like that both from a product development perspective for Atlassian and from an admin perspective.
Shoutouts & Kudos to:
Jonathan Cyr - who made a great point about using this in a sentence in English 👏
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.
Oliver Michael I'm New Here November 20, 2024 How will this affect fields in JQL search? E.g. currently, I can search for `issueKey = X` - will this now be something like `workItemKey = X`? This affects many other fields related to issues / work items?
This. Exactly this. Am I going to need to update all of my filters and JQL queries embedded in Automation rules now?
Atlassian wastes time on changes no one asked for while ignoring their 20+ year backlog of valuable feature requests. Everyone is going to continue to call these tickets or tasks regardless of the issue type.
@Brock Jolet Considering how smooth the transition from "Epic" to "Parent" was, I doubt Atlassian's change plan was just shrugging their shoulders and telling everyone "good luck". Heck, users have been begging for this for years and the massive Change process required to overhaul such an integral component of the software was always one of the top reasons why it wasn't possible.
I have had such a hard time getting prospective teams/users to look past the word "issue" to use the tool - I suspect this will be much more popular than what is seen on this thread.
Having everything called issues is bad (and let's not forget that service desk has both issues and requests).
But calling it work??
So a user submitting a ticket asking a question is "a work"?
For those using a jira project for asset management (the old school way, not the overpriced jira permium asset management way), a computer item is now a computer work?
Better to leave it as "issues" until you come up with a proper alternative. And what kind of "research" is done and a solution decided and implemented in just 3 months?
Better to spend time fixing search, fixing UI inconsistencies all accross the place, fixing the messy vocabulary and management of users, agents, portal customers, etc... or the myriad of 20+ years feature or bug-fix requests in the backlog..
Maybe they used that "Atlassian Intelligence"...
Update January 2025: today I got an email letting me know about tickets with today's Due Date... Even this email is inconsistent. Email says "work items", email headline says "items", text says "work", and button says "work items"...
Also, how many years has it taken to have reminders based on Due Date..? and yet..
This notification does not tell me anything about which project they belong to, not even which site or tenant, nor the type of issue (sorry,work) or anything else.
My custom-made emails via Automation show the issuework item key, requestissue work type name, and the summary title of the work issueticket item, and their current status.
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.
1. I am assuming this is also going to move through the Chrome plugin for testing > Beta > Enabled on nominated sites > Interviews > GA? (similar to the new naviagtion) Is that right?
2. If so, is there an estimated rollout plan for this?
3. I would also like more clarity on what is replaced exactly on the interface of Jira, JSM, Confluence, Bitbucket, etc? Ie. screen shots or exact indications of everywhere the "find and replace" will occur. That would be really helpful, wouldn't it?
4. Lastly, referring to this
"Q: Can admins choose what term replaces 'issue'? Will this be a site or project-level setting?
No, admins will not have the option to decide what term replaces ‘issue.’ By default, ‘issue’ will be replaced with ‘work item’ for all Jira customers at the site level"
And on here https://www.atlassian.com/blog/jira/work-your-way - it seems that admins can have the flexibility to chose - so I suggest this becomes something configurable instead of it being changed for us. Thoughts?
Hi, I prefer the classic terminology, but my concern is that.. How this change will reflect on the result api call? example for the issuetype attribute? I hope it will not change in worktype. I have billion of scripts for customers or jira expression in validators... please give feedback about this topic
I like the term "work" because it is neutral and reflects the idea that something needs to be done.
However, I would like to know if the term will also be translated into other languages.
For example, in German, "issue" is translated in Jira as "Vorgang," which implies an active process (work in progress). In contrast, "work" would be translated as "Arbeit," which suggests something that needs to be done (work ahead).
Am I missing something here.... but if you are going to do an overhaul of something like this... why not make it configurable for the Admins in the first place??
When I design systems... the first thing I think about is Taxonomy - becuase it's REALLY important, and it's often overlooked in system design. But people are passionate about what they call things.
If I was overhauling this. I'd simply have two config items for "Issue", and plural "Issues", and convert all instances of the use of the term issue/issues into a read from configuration. e.g. Create issue, Change issue type, Issues.
Then release the config to admin who could set it to whatever they like, or leave it alone?
35 comments