Atlassian just announced a new feature for Jira Cloud users: anyone can create a project, issue type or custom field. No need to engage the admin team! When I heard this at the Summit user conference, I cringed at the thought of cleaning up the new messes that end users will inevitably create. I’ve spent many years fixing poor decisions made by application admins and now end users, with even less knowledge and application management experience, are unleashed on the config? Yikes! A fellow conference attendee sitting near me exclaimed “but I just got our application cleaned up” and let out a large sigh. Atlassian also announced the 2,000 Cloud user limit is upped to 5,000 users. Now even more people can create a bigger mess!
A theme throughout the conference was “open.” It means being open in your communication, your intentions, open to new ideas, and more. I enjoyed that talk and I took it seriously. So, I’ve challenged myself to reject my original pessimism, embrace this change, and find the good in it. I spoke with a Jira Software representative at Summit but initially that didn’t ease my fears. It wasn’t until I tried out the new project creation feature that I calmed down, the fear subsided, and I saw the potential. I can appreciate Atlassian trying to simplify a complex process and free up time for busy application administrators. This also aligns with the concept of added workflow and screen editing abilities introduced in Jira Server versions 7.3 and 7.4. And yes, I was scared of those changes at first too. But guess what? The world did not explode and I didn’t have to fix too many botched workflows. 😉
Good to Know
These new project abilities are configurable. It’s a global permission, so you can decide which groups receive the power. You don’t have to use the default “Anyone” setting.
Projects created with this method are structured totally different from previously created projects. These projects are independent entities that don’t impact or share schemes with the other types of projects. I know what you’re thinking: sharing schemes is “the way” to easier maintenance! It will be interesting to learn how best to manage projects built in two very different ways.
I created a project of this new type, created a new issue type, and a created a new custom field. Since these objects are decoupled from global settings, there’s nothing I’ll actually have to clean up later at the application level. For example, there’s no new entry on the Admin > Issues > Custom Fields page. I wonder how these objects are stored? Since this is Cloud, I can’t access the database to see.
The new issue type creation wizard prevents you from creating an issue type that already exists, which is great news. See screenshot. But, it can’t prevent other “human caused” problems, like dupes (think “Bug” vs. “Defect” in the same project), plurals, and misspellings.
As a test, I created a new issue type and called it “Epics” (with an “s”.) Now the test project has both “Epic” (which has the special association behavior you expect), and “Epics” which is simply a standard issue type. It’s not pretty but luckily this unfortunate action is constrained to the project where the issue type was created. All users will see both options in the JQL search however.
I also created a custom field with the new fields designer feature. I created a field called “Date” and selected the type as “Text” instead of “Date” like it should be. It’s a common mistake and end users are bound to make it. In the screenshot, you can see my lovely new field on the right and its purposefully ridiculous value. Again, since this unfortunate decision is constrained to the project, maybe it’s not too much of a problem. This team won’t be able to properly sort or query data in this field, but it’s not the end of the world.
This leads me to my only real gripe. Atlassian also announced a project archival feature (yay!), but it’s only for the Data Center version of Jira. I think the Cloud version needs this feature now more than ever!
What happens when all your users create their own personal projects for every little item on their “to do” list? How does an application admin clean those up when they aren’t needed or when the creator leaves the company? What happens when you visit the “all projects” list and there are 500 more entries than there were yesterday? How does a user know which “Marketing” project to file their issue in, now that there are 5 to choose from? I’m not sure there’s a good way (yet?) to manage these scenarios. A bulk clean up tool is really needed.
Also, my Cloud instance is very small, yet very slow. I know performance is improving and is a priority. But I worry that adding all these extra elements (even the cool new stuff) could slow it down even more.
After my very brief look into the new features, I’m willing to be open. Change is hard but I’m choosing to embrace it. New concepts and features certainly deserve a fair shot. It will be interesting to see what, if any, issues arise and how application admins can best address them.
What do you think? Are you open to this change? What are some pros, cons, scenarios, and considerations? Post your opinions in the comments field below.