User: "I don't have access to the space that a co-worker has send me."
Us: "Do you mean a Jira Space or a Confluence Space?"
"An eternity later..."
User: "Jira".
Us: "Ah, thank you. I will have a look for you."
---
This change doesn't make sense at all. I do get changing the name in Jira to something other than 'Project'. But come on. Please use a name that was not already present in Confluence. This is going to be so confusing.
Got a question in regards of those users which will be trying to migrate from DC to Cloud due to DC decommission?
How JMCA will manage migration of filters which was using: project = "something" ? Will this be automatically converted to "new way" which is used Cloud? or will it be broken and manual fix ( project is now space) - for all migrated filters needed?
Stop, please just stop. I don't know how else to say it and I'm fairly certain no one is listening anyways... this is change for the sake of change. "Spaces" is already in use and will just confuse end-users. You've become too 'in the weeds' with your own products and forget what it's like for a new user to adopt this vs. other platforms. Listen to your allies who are trying to champion your tools within their organizations and walk this one back. It's utter nonsense and creates noise at the executive level when budgets are already being scrutinized. At a time when every org is making decisions about what is mission critical, I'd suggest strengthening your partnerships, not finding creative ways to drive a wedge between your products and your customers.
How about this... for projects that are actually projects, create a concept where projects actually go into and "space" (bad name btw) for the non-project stuff. some of us actually have projects but we also have workspaces (that's a better name).
Space in Jira and Space in Confluence are very confusing now.
Should we be changing our roles from project-admins to space-admins now but needing to specify that it's JIRA-space-admin and not CONFLUENCE-space-admin? it's soo confusing now!! instead of changing the name of projects, just create a new category of work that's operational-oriented. The opposite of Projects is Operations. That would be been a way better name compared to "Spaces".
I still don't understand how Atlassian Projects even interact with our jira software project types, oh wait. can't call it a project type anymore. It's a space type now.
stop changing names, it's prohibitively expensive and needlessly confusing. like how Toronto decided to change the street Dundas Street because it had slavery connotations and it ends up costing taxpayers millions of dollars.
instead, focus on bringing more value. a name change does not bring value to its customers. we're paying a lot as is and it's getting more confusing and convoluted. My job is to smooth the riot from happening internally so that we keep Jira and Confluence.
Personally, I find this latest change from projects to spaces a serious irritation. So we have spaces in Confluence and now spaces in Jira. I think Atlassian need to "apply their minds" more when thinking of more ways to disrupt their clients. LAstly, I think Atlassian need to slow down with all these major changes to the applications. If something works, don't break it.
@Josh SherwoodI’m curious whether the Atlassian team is fully aware of the significant pushback this change is generating...
The introduction of “Spaces” in Jira has received widespread criticism, and many comments expressing concern have been met with strong agreement from the community. Yet, there appears to be little acknowledgment or engagement from Atlassian on any of these concerns. As one commenter aptly stated, this feels like “a solution in search of a problem.” Why alter something that no one requested? None of us - whether managing a few licenses or, as in our case, 2,400—were looking for a “Space” for collaboration. We invested in Jira as a project management tool. This shift marks the transformation of Jira into a product that many of us would not have chosen in its current direction.
Atlassian often emphasizes its commitment to supporting agile practices, but this change seems disconnected from customer needs. Why is there no visible effort to review these decisions with stakeholders or incorporate user feedback? Listening to your customers is a cornerstone of agile, and right now, that principle feels overlooked. - Casper
"For many teams, 'projects' are often understood to have defined start and end dates, hierarchical structures, and clear scopes. However, Jira ‘projects’ function differently – they're containers for work, not tied to the traditional definition of a project.
Furthermore, we've recently introduced Atlassian Projects, purpose-built to provide high-level visibility into work with defined timelines, goals, and stakeholders. By renaming Jira 'projects' to 'spaces,' we’re making it easier to distinguish between these two features and their unique purposes."
So....Atlassian Projects are addressing the ability to have defined timelines, goals and stakeholders.
Help me understand how the current Project functionality limits the ability to do the above?
Lastly, this statement...."However, Jira ‘projects’ function differently – they're containers for work, not tied to the traditional definition of a project."
So... the traditional definition of a project isn't a container for work? What is it then? If the general idea of "projects" has "defined start and end dates, hierarchical structures, and clear scopes," then how is that not related to some sort of work product?
To the executive management of Atlassian...can you not see that the above seems to just serve itself and not be a 100% value-add for many current users who just want to get work done and be able to depend on a product to only make changes if it truly is going to make their jobs easier?
This doesn't appear to be one of those changes and seems to meet the definition of an Excel circular reference error.
For those who are responding with the agreement that the change is necessary, help me to understand the logic behind that.
If you or your company purchased Jira licensing, it was with the understanding of it being a "Project Management" tool. Even if it was included in a suite of products and was never your initial deciding factor, the fact it is a tool specifically for managing projects should have been well understood before use.
By indicating now that the word "Project" never made any sense to "how we use it" only implies you were trying to use the wrong tool for what you wanted to do. That would be like someone purchasing a hammer and using it to drive in screws. Yes it can technically get the job done, but deciding to change the name from hammer to screw driver because "that is how I use it" would make no sense.
I am just completely baffled as to why this is even a decision from Atlassian as well as any agreements to it from users.
@Chris Calvert and others, maybe these details will help (I will try to stay away from the two terms in question).
From what I have seen across multiple companies and Jira sites is that this particular thing in Jira is typically used as a forever-living area. While some are archived/deleted, the typical use-case is that there is an initial setup and then the settings within it may be constantly adjusted over time and new features will be added in, but it lives forever for many years with no end-date ever intended for that particular team/product/service/topic to track work.
Because Jira can be leveraged for really complex setups in workflow and collaboration, that makes a lot of sense to not start from scratch in the majority of cases from what I have seen (when you make a new one of these, all sorts of integrations/automations/identifiers would need to be adjusted in a lot of places).
Also, there is a lot of types of work that happens layered onto the related tools beyond the tracking that you are mentioning that will never have an end date and they share the term (there is Jira Service Management support flows/changes/incidents, ideas in Discovery, software releases, personal task tracking, team task visualization, reporting, etc.).
Furthermore, I'm not sure if you have utilized the Platform Experiences in Atlassian Home, but they are built to be short-lived with status updates and end-dates and they were also sharing the term (creating additional confusion): Atlassian Home - Platform Experiences details
To summarize, I think it was mainly to clarify that the overall section that contains work and controls the settings of how work functions within it is not a temporary endeavor. There could also be some plans of making a cohesive "Atlassian" setup above the individual apps that others have mentioned so that documentation and work can be quickly accessed in the same area (I'm not sure about that).
Hopefully this helps a little (I am obviously not privy to all of the details around it, but I can see how the prior term was not aligned to how Atlassian wants to make Jira contain work of every type for every team). I think the prior term was always describing a lower level item that lived within these sections from how I was seeing Jira used, but maybe you were spinning up the top level in that way.
Can you please confirm that Release Tracks will not receive this change until December 9, 2025, as posted here:
I only ask because in my Admin console, the Rollout schedule for this change still shows "No timeframe yet" for my sites on Bundled Release Track (this would be for FD-112177).
I agree with everyone above about this confusing and unnecessary change. I mean you've had 10 years since Project Central was talked about at Summit 2015 and the best you could do was to co-opt a term that has been in use for over 21 years (Confluence released 25 March 2004)?
That said I'm happy that being on Release Tracks allows me to give my users a heads-up. Assuming you stick to that Dec 9 date.
@Greg D I understand what you are referring to, and we even have some "Projects" in Jira that are not standard projects in the strictest of sense. But what you described are just examples of things that can be ADDED to the offerings by Atlassian instead of breaking something that is already working very well for the vast majority of users. I used the word ADDED here because the premise of providing a solution to encompass the needs of many different companies, departments and people is something that should be new and not a replacement/crippling of something that already exists.
If Atlassian decided to come out with a new service that provides the concept of "Spaces" as they intend for Jira (not Confluence, forclarity) (again, a very unwise decision to name it thus) I am certain it would be very welcomed and provide even more income for the company. That way everyone would have what they are needing to use in whichever way they are needing to use it. No confusion necessary.
But instead we are served with the idea that we have all been managing our projects, sorry, spaces incorrectly and we need to be treated as though we are children. Told that projects are not actually projects and we need to adjust our way of working to accommodate other departments that manage work differently than us, taking the tool that was designed specifically for project management and sacrificing it for the greater good!
I have also heard people indicate that this is "only a name change, and everything else is the same". Even if that was true (which I do not believe either), it still causes complications and confusion with a lot of training and support documentation. But, in my humble opinion, I think Atlassian is just starting with the name change and will be changing how the program works and how you work with it. The wording of the reason for the change can only mean that it will need to change how it works to accommodate the needs it describes. Just changing the name does nothing to accomplish that goal.
Seems like non-optionally changing a straightforward word into a very arbitrary one, creating a collision with existing terminology in another part of the system is a pretty questionable choice.
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.
@Josh Sherwood this decision is poorly thought through as all of this initially started with managing code development and the concept of a 'Project' is a well defined, and known term, by programmers, business users (when launching any change) and well understood by everyone else on a change effort. Furthermore, it's used across various industries in software development, infrastructure cloud providers and businesses whether public or private.
This change should be abandoned as the marketing benefits outweigh the costs. Please focus on the product these name changes have been quite frequent in the last 3-6 months and have not done much other than confuse people who are more interested in the product itself.
First, they could have added a start-end-date feature to projects as an optional toggle in a project's settings page.
Then, they could have released workspaces (so much talking about "work items" and they didn't go with workspaces...) as a highe-level concept that would could then contain projects (dated or not) and whatever else.
These would have been incremental add-on features that would not have broken or interfered with anything, would not require renaming all APIs and scripts (eventually, when they change to be called spaces instead of projects). They could have even made them paid add-ons (since they like so much to be always upselling something).
Finally, in reference to Greg D's comment, I think the only reason why people keep endless projects active is because of how terribly convoluted, complex, and heavy projects in Jira are to start and close; and because for some reason archiving a project— that is, ending it... — requires paying a premium.. (why?). So, of course we keep projects open.. or are we supposed to delete a project and lose all its history and comments or attachments forever? Instead, we end up forced to keep endless projects, and treat Epics as projects. it's ridiculous.
Making it easy to start/close projects, and fix all that mess of schemes all over the place that require a full-time jira admin to manage, and then people will use projects as actual projects. But, that would require having to look deep into their technical debt, which nobody seems willing to do, instead coming up with replacements to throw away the old stuff with new but broken stuff (new navigation, new lists, inconsistent/still-unfinished migration from issues to work items, etc)
I definitely understand all of your perspectives and was trying to stay away from the terms themselves, but I do find it interesting that you all are saying that you have always considered your "project" tracking to be at this top-level Jira workspace and that your preference would be to keep spinning up new big containers with tons of powerful features and setting adjustments necessary for each new project over having multiple projects live within it or the new projects app that attaches to it. Definitely interested in learning more about how other groups use Jira.
I think what I was trying to convey is that the majority of people that I have seen are tracking their many projects within a single Jira workspace and other connected apps (many projects constantly happening within one Jira container that they tweak the settings of over time to work to support a specific long-lived work function that can drive many projects to completion). And then they would only archive/delete the container when that work function is no longer needed. I do think there is a lot of value in how complex you can make the setup within one Jira workspace container and how that changes over time.
And I think they kind of did what you are saying @Rafa, but they introduced the more status-update-aligned project concept to keep people in the loop as the newer item that came from Atlas since they saw the majority of people building long-lived containers that they were happy with on the Jira side. Atlassian simplified how to track actual projects quickly in the Home Platform Experiences setup in a much more lightweight approach (that is being transitioned to become a Projects app like Goals that can be attached to your work items in the space).
I was originally frustrated with the name change from issues to work items as I still felt that "issues" is a flexible term. However, I did see a lot of confusion between the newer Atlassian Projects that have been around for a while and what had carried that name for a longer period of time. I think because of my experience with many people liking these spaces to be long-lived, complex work containers typically attached to specific teams and products and functions that can share standardized best practices and evolve over time to complete a variety of work, this change has made more sense to me (or maybe I have just reached the peaceful acceptance stage of grief quickly).
Definitely not trying to stir the pot and just hoping to help other fellow admins with some perspectives.
70 comments