@AdarshSinghMaheshwar I tried to ask the Atlassian content designer Josh about this here, but I have not heard anything back.
Are you all also addressing “project” along this journey of change?
That has always been a weird term since a “project” would have an end (and most Jira projects never end). Atlas uses the term project and that is getting folded into Atlassian Home/Platform Experiences, so now there are two concepts of projects (with Atlas actually being the more accurate usage… but it is newer, so maybe that one will be re-termed?). It probably makes sense to change both and call the Atlas version segment or stream or milestone or initiative or program or loop
Feels like “workspace” could replace “project” since that is more accurate… or something similar to space could be appropriate… I can even see how “work” might fit better at that level instead of the issue level (although there is more than work in there and it still falls down in places such as “We should create a Jira work for that.”… “We should create a Jira workspace for that.”
If you are altering a bunch of things with renaming issue, you could tackle project at the same time (I saw more problems with the term “project” and thought “issue” has been much more flexible… sorry for opening up a can of worms everyone)
In the most used screens in Jira, you will see the work type rather than the collective noun ‘work item’ where it makes sense. For example, when someone creates a ‘bug’ work type, they will see ‘Created bug’ rather than ‘Created work item’. This is something we’re working on and is not part of this release.
We’ll be rolling out throughout March through to mid-April.
Changes will roll out within all Cloud products at the same time.
We’re working to update our customer-facing materials at the same time as our product roll out.
We’ve turned off the Chrome extension. We’ll remove the link from this post.
I spent all day yesterday updating our use of “Issue Type” with “Work type” throughout our workflows, so backward compatibility was NOT maintained for this change. Even the case of the term “type” dropped from upper to lower. Epic fail. So many tickets got out of sync between the cross-functional workflows we’ve designed that, once the fire was out, repairing the damage done to our complex flows is ongoing.
Did I say, “Epic fail?”
Oh, yes indeed, I did. But I cannot say (or shout it) enough: EPIC FAIL!!
And all for what I see as a trivial change that provides no real value and only serves to add RISK to the environment. WEAK!!
I’ve been using Jira with the term ISSUE for decades. And I’ve never even given a fraction of a though to that term being an issue – pun intended.
This is the THIRD time in two months I’ve had to stop productive progress to repair messes made in an environment that clearly lacks any adherence to the QC and change management principles that have been developed over decades of “oops” moments and hours-upon-hours of post-mortems to prevent stuff like this from happening.
Did I say, “Weak?”
Oh, yes indeed, I did. But I cannot say it enough: WEAK!!
I wish the tone of this post was more positive, but I also wish that Atlassian would stop changing things for the sake of change and focus more on keeping the cloud environment STABLE for my clients.
Hi @AdarshSinghMaheshwar ,
I wanted to ask if the Get Field List API will return Work Type and Issue Type field both?
I checked for one of our instances, we were only getting Work Type field in API response.
Will it be fixed in coming days to make it backward compatible?
What will be the behavior of this API?
There are no changes to existing APIs; they will continue to function as usual with the term “issue.” This approach ensures that no backward-incompatible changes are introduced.
Does this expand to adjacent words like issueType?
Is backwards compatibility guaranteed on data in response objects, too?
How long will the old ‘issue’ JQL syntax be supported for? For example, a Jira filter using the JQL “issue in (1111, 2222, 3333)” or “issueType in standardIssueTypes()”.
Also, I think it is confusing to update the JQL documentation to the new syntax e.g. “workType in standardWorkItemTypes()” before it is live on every customer instance. Using this syntax will currently result in errors e.g. Field ‘workType’ does not exist or you do not have permission to view it. This makes the JQL documentation inaccurate in some cases.
The switch from “Issue” to “Work {Item}” just happened on one of our Cloud site.
Is there an API that we can call to get whether to use the old term ‘Issue’ or ‘Work {Item}’?
So, my question is, is this page transferred already or when do you plan to finish most important pages / sites? Or, is this is proper use of the word “issue” by the new rules?
Are company managed project permissions going to change as well? (At Jira Settings > Issues > Permission schemes, Permissions). It still contains permission names like Create Issues, Delete Issues, Edit Issues, … We need to describe to our users how to set up Jira permissions suitable for our tool.
About issues in permissions: Josh Sherwood has replied in user forum:
We’re aware of some terminology inconsistencies in our admin experiences, particularly regarding the permissions you mentioned. Our team is actively working on addressing this issue, and updates to these permissions should be made soon.
