I would like to become one of the Atlassian community all the way from Nairobi, Kenya and I am a company marketing here, so I am really frustrated how to join and have my own dashboard to make my project so far I have tried for a couple of hours but no result, actually desapponted by
@Nikki Zavadska _Appfire_ I hadn't seen that yet, but I think that is a really good breakdown of what you are getting into with the features that you will not have if you choose Team Managed. When it was called NextGen, people went that route by mistake way too often.
I think these templates and descriptions are really nice for brand new Jira users. I still wish that there was a way to quickly skip all of this templating for when you actually know what you want. My use-cases never fit well into any pre-conceived bucket and so creating new projects now means that I need to pick any template (just for fun) and then share the settings with an existing project so that I don't clutter the entire instance with a bunch of things that are not needed.
@Bree Davies , in my opinion what we really need is to be able to start in a way so that no new fields, no new statuses, and no new issue types are built when we create (but have all of our schemes pre-built for us and only pointed to the new project). One way to do that would be to allow template creation (but that is more work on your end)... so if you do not want to allow our own template creation, then if you could give us an empty template called Just Schemes then that would help too. This would probably be the easiest approach for you so that you can keep control of template creation (and not need to work on a UI for that).
You can add some new things into an Advanced category that would include that just schemes template, a share existing project settings template option, and a copy from an existing project. If you choose Just Schemes, you will create a project that only adds an Issue Type Scheme, Workflow Scheme, Screen Scheme, Issue type screen scheme, Field configuration scheme, Notification scheme, and Permission scheme with the project key and what it is (e.g. TEST: Issue type screen scheme). If you pick Share Existing Settings, that would immediately send you to the final screen with the share settings box checked and greyed out (leverages existing functionality, but skips a bunch of clicks for us). If you pick Copy Existing Settings, that would let you pick a project and similarly to the "Just Schemes" it would spin up new schemes that match your source project with the new issue key as its naming convention, but it would also spin up actual workflows, screens, and field configurations that are new but that match our source project and it will put those into the brand new schemes. It would also be preferred to copy the entire project settings exactly as they are setup if you pick that option (today you need to go and repeat all of that setup even if you choose to share settings with an existing project).
All of that would save us Admins a ton of time and support infinite use-cases. Like others have said earlier in this thread, you don't need to be guessing what our unlimited use-cases might be and spinning up more and more templates. You have a great template library now for someone's first rodeo into a particular use-case. Once we establish what we need from a setup perspective, we are far more likely to repeat our own custom setup than to be using a new template. Thanks!
Thank you @Bree Davies for sharing the background behind new terminologies. I liked, "Change is an adjustment". The new Jira terms are meaningful for Scrum team members to identify their purpose.
It looks like my Classic project just changed into the community-managed project. Unfortunately, this looks and feels exactly the same way that the next-gen project did and is the exact reason why I did not go with next-gen project back when I was creating my project.
All of my . shortcuts have disappeared. I used to be capable of clicking into a ticket and updating all the necessary fields quickly without having to move my fingers away from the keyboard. . epic . labels . link . upload document . comment . assign. Clicking and moving a mouse around is taking away my time. Please bring back the power-user shortcuts!
Or at least tell me how to enable these... I did not think a name change to the project would introduce so many changes.
Atlassian Team members are employees working across the company in a wide variety of roles.
April 28, 2021 edited
@Steven Braverman Hi Steven, I'm sorry to hear this! But you're right, with the project type label change, we did not introduce any functional changes or 'switching', so it sounds like something else is at play here. All that should have happened is text changes in the navigation bar inside of your project. I'd recommend you open a request with our support team, who will be able to troubleshoot this for you. https://support.atlassian.com/jira-software-cloud/ All the best, Bree
Thanks for sharing Bree, this was helpful. Wondering what the cycle is to remove the information floating around still referring to Next Gen templates. Hope it gets cleaned up soon.
It doesn't matter what you call it—"next-gen" or "team managed"—that product was not ready for prime time and unless you've made it usable I don't recommend anyone use it.
Sorry, Jira has some real problems and is getting a bit "long in the tooth" so changing the name of something strikes me as tone-deaf to the problems users like myself had with it.
The fact is Jira is as byzantine and convoluted as it has ever been and THAT makes it unmanageable to 90% of folks out there. I would suggest focusing on that instead of changing the name
Just to say I have been using Jira for about 10 years now. Well before Team Managed Projects became a thing.
I have never understood themes although there would have been a few times when it would have been good to.
Thanks for your diagram John but I'm sorry to say I still don't get it.
I saw someone (perhaps on this topic or another) say Jira was byzantine. I think that's probably pretty accurate but I don't agree it makes Jira unusable. I haven't found anything that comes even close to matching it.
Perhaps if I absolutely had to understand schemes I would get my head around them.
I think all this has to do with the way Jira came to be and was built by nerdy (term of affection rather than disparagement) developers for nerdy developers. I really hope no-one takes offence at that because none is meant. But the world has moved on and the tools we use have moved on.
Of course those tools all have the advantage of being superseded by new tools. Jira can't do that. The code base must be enormous. So although there are lots of things about Jira that remind me that it was built in an earlier time, it's still (head and shoulders) best in its class.
If you ever get a chance to have another look at schemes that would be great. If you don't, I can live with that.😀
@Chris yes, the at-mentioning in these community articles only reliably finds the last 4 commenters and the author (it recommends those when you first type @... but then if your name is unique enough you can get it by typing more characters).
Schemes can definitely be confusing.
I would summarize to say that schemes are just bigger groupings that can be re-used to drive your setup across projects. Let's say you create a new project... you may want to use an existing set of issue types in it (you pick your scheme of the set of issue types that you want from your already existing "templates" that exist at the instance level - issue type schemes)... then you might also want to use a different set of screens (pick a different scheme for that piece)... then a combination of workflows (pick a scheme for that or make a completely new one since this new project's workflow might be all different). It really allows you to template each piece of your setup along with being super customized for a new use-case (instead of just picking a template for the whole project when you create it).
I think it is helpful to take a step back on company-managed projects to realize that an issue type is your foundation and then you can configure any part of that issue type to behave differently on a per project basis (the schemes are what is mapped to the project to allow the mix-and-match functionality). One exception to that rule is that in New Issue View, the view screens are now outside of that control (and for Jira Service Management you can split one issue type's view screen for every Request Type).
One downside to schemes are that you need to be a Jira Admin to control them (enter Team-Managed projects). But you can essentially share setups for each part of the Jira configuration (so if you need a field to be hidden for a bunch of projects, you could do it in one place).
Some downsides to Team-Managed is that you cannot mix and match pieces of your project from other projects' setup and you also cannot make a single admin update anywhere that affects multiple projects (lots of admin updates needed to make a multiple project change). But you can let people have full control over a single project that would have needed a Jira Admin for certain changes.
Anyway, I probably just made it more confusing, but hopefully some of that helps.
For me, there are features that are useful in both but cant be combined. I like the templates but again there are features in those which can not be adapted to a scrum of Kanban template. I also recommend someone looks at the kanban template as everyone is trying to hack it to do what we would consider being a Kanban board.
being able to turn the list view and calendar on other types of projects which can be customised would help some.
140 comments