We're moving! The community forums are migrating to a new platform on September 22. Learn more
×Community resources
Community resources
Community resources
The Issue with Spaces and Work Items
What Terminology Changes Really Cost
What’s in a name? Quite a lot, when that name is embedded in URLs, APIs, JQL, documentation, user habits, and AI.
When I recently moved to Jira Cloud as a technical writer, I soon realized that I had arrived in the middle of a language migration. Issues were becoming work items. Projects were becoming spaces.
This migration had already been underway for quite some time - and it is still far from complete.
After about 15 years as a Data Center end user, I had to complete my job application task in the somewhat unfamiliar Jira Cloud interface. Most of it felt fairly intuitive. There was just one question I kept asking myself:
What the hell is this new thing called a work item?
By now, I know Jira’s new terminology fairly well, along with the reasoning behind it. Yet I still encounter old and new terms across documentation, Community answers, JQL queries, smart values, APIs - and Rovo.
A quick detour into terminology
As a technical writer and UX writer, I spend an arguably unhealthy amount of time thinking about terminology: how we give concepts names that people can understand, remember, discuss, and search for.
The requirements sound simple. Terms should be clear, distinctive, consistent, and suitable for their audience. And, of course:
One term, one concept.
That is the deceptively simple advice offered by classic technical-writing guidance and authorities such as the Microsoft Writing Style Guide.
But how do you find that one term? Easy: speak the language your users speak.
Except that users do not all speak the same language. Different people choose different words for the same thing, and there is rarely one term that everyone would naturally use.
And that is only the challenge of choosing a term in the first place. Changing a term that has already been established comes with problems of its own.
From a UX perspective, words provide what the Nielsen Norman Group calls information scent. People use labels, context, and previous experience to decide where an action might lead. Change the label, and you change one of their navigation signals - even when the feature behind it remains untouched.
A quick rename?
Jira’s issue terminology reflects its history as a bug tracker. But Jira stopped being just a bug tracker long ago.
In March 2025, Atlassian began rolling out work item as the replacement for issue. Three months later, Atlassian announced the next major change: Jira projects would become Jira spaces.
Many discussions have focused on whether these terms were well chosen. That is not what I want to discuss here.
The interesting question is what happens afterwards - especially when you rename two of your software’s core concepts within such a short period.
Atlassian summed up the project-to-space change rather dryly:
Projects have a new name. Everything else is the same.
True - and not true.
A central Jira term does not live in a single interface label. It lives in documentation, onboarding material, certifications, support conversations, screenshots, search queries, Marketplace apps, Community answers, integrations, and code.
You can replace a label.
You cannot use Find and Replace on collective memory.
At rollout, Atlassian was transparent about the technical boundaries. Existing APIs would not change. JQL would continue to understand project. Automation smart values would keep {{project}}.
So what we got was quite a nice mix of old and new terminology. And that is without even getting into Data Center.
New terms, old habits
Long-time users did not receive a vocabulary factory reset with the rollout. Issues and projects remain muscle memory for many people across the Atlassian ecosystem.
Newer users learn about work items and spaces directly from the interface. But this is not simply a clash between old and new users. Jira Cloud itself changes dialect depending on where you look.
The navigation says space. JQL says project. Current documentation says work item. An API endpoint says /issue.
Each term is correct in its context. They just do not make it obvious that they all refer to the same thing.
A Community question may refer to a space while an older - but still valid - answer calls it a project. Someone may search for work items while the most useful troubleshooting result still talks about issues.
Take The Jira Guy’s excellent guide Your first steps on Jira. As of September 9, 2026, its introduction to basic Jira terminology still teaches issues and projects. The knowledge remains highly useful, but its terminology can be misleading - especially for people new to Jira.
Must every valuable article ever written about Jira now be rewritten?
Terminology fossils
The old terminology is not dead. It has simply moved into deeper layers of the system.
Take the current Atlassian support page titled What is a Jira space?. Its URL still ends in what-is-a-jira-software-project.
The Jira REST API still has an API group for issues. JQL, integrations, and automation preserve established identifiers because changing them could break working configurations.
I understand the reasons behind each of these decisions. Backward compatibility and durable links matter more than terminological purity. Still, every inconsistency hurts my little consistency nerd heart.
So this is the deeper layer behind a quick rename. Some old terms survive as fossils in URLs and APIs. Others remain as echoes in documentation and Community discussions.
And some return as ghosts in AI-generated answers.
The terminology update Rovo forgot to load
Rovo, for example. Many of us have encountered the rather absurd situation of Atlassian’s own AI insisting that spaces are Confluence terminology rather than Jira terminology. Community member Brock Jolet illustrated this very nicely in his Community article. He asked Rovo to review some documentation for errors. Rovo flagged references to Jira spaces and explained that Jira uses projects, while spaces belong to Confluence.
It even warned that the new terminology might confuse readers.
Rovo did not merely miss the terminology update. It tried to roll it back.
And that brings us to the real issue.
A terminology change is a knowledge migration
The interface can learn a new term overnight. Users, documentation, URLs, APIs, Community answers - and AI - cannot.
The old term will not simply disappear. In a mature system, it often needs to survive. The challenge is to keep the bridge intact. Old and new terminology must still lead people to the same knowledge, while the context makes clear which term belongs where.
The new term gets a launch date. The old term does not get a retirement date.
So, for me, this is the real cost of any terminology change - however good or necessary it may be. A name is an access path to everything we already know. And that bridge must never be burnt.
I am curious: How are you dealing with Jira’s terminology changes? Which terminology fossils have you encountered, and how are you handling older content, search, and findability?
Was this helpful?
Thanks!
Evelin Bayer - codefortynine
9 comments