For a few versions now, the new project wizard in JIRA seems to want to create a set of schemes (workflow etc) per project when creating new projects.
The new direction seems at odds with the performance data and guidance of the past.
I believe most of the white papers, and presentations at Atlassian Summit promote fewer workflows as being beneficial to performance and scale.
So while I'm aware you can still punt the wizard, and create a bare project to associate with existing schemes (or use templates), is this "old school"?
Is allowing each project to have it's own set of schemes OK now, especially in larger enterprise systems with hundreds of projects?
In my experience, having per project workflows is absolutely okay, and is ultimately ideal for scaling and ease of administration. From a performance perspective, yes, it'd be ideal to share as many schemes as you can across projects, but it's potentially dangerous as the number of projects grow, (for example, accidentally changing a workflow that's shared across many projects), and needs evolve. I can't think of a single time where I've been able to attribute per project workflow schemes and/or other schemes as being a major culprit for performance degradation.
(In my experience, one of the greatest offenders, (from a performance perspective), is having a huge number of custom fields.)
So, I say go for it. It just may make things easier for you in the long run.
I just +1'd that - huge numbers of workflows have never caused me a single performance problem.
Complex permission schemes, too many users, too many silly filters, extracts or integrations, yes. But not too many workflows, or screen schemes etc.
I'd agree that the current limbo is a pain in the neck though. As an admin, I like users to look after themselves, but also despise having 30 teams doing the same thing in 30 slightly different conflicting ways. We now have the worst of both worlds - Atlassian actively encouraging individuality without doing anything to help admins manage or delegate it properly. I'm hoping they get a grip on it soon, make a decision one way or the other.
It is semi-disfunctional.
On one hand, I like the notion of having per-project schemes, it cuts back on the number of "yeah, I can't do that without pissing off teams a b and c".
On the other hand, if I give teams per project schemes, it's going to be a cluster-f trying to make change A apply to these 90 projects, 25 of which the change will break....
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs