Users Create Jira Projects. A Good Idea?

[#1]

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!

President Jay Simons: Open & Fluid

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

"Create independent projects" Global Permission

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.

Quick Tests

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.

Duplicate Issue Types

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.

Poor "Date" Type Choice

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.

One Observation

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.

Being Open

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.

Learn more about these features in this post or watch the Summit keynote starting at 1:02:50.

[Nic Brough -Adaptavist-]

I always liked the Confluence approach - being able to grant "Space (Project) create" to a limited group.  If nothing else, it means you can say "yes, you can have this right, after I've beaten you over the head with a rule book so I can trust you not to make a mess"

[Deleted user]

Thanks for the write up and especially for being Open to Atlassian's new approach. I remember sitting next to you and some other AUG leaders (aka Jira admins) at Summit 2017 in San Jose when the concept was announced for the first time and everyone was shaking their heads as a first reaction.

Like Atlassian said: Cloud customers are a bit different than Server customers and have different use cases. So the more open approach makes probably sense for these new kind of customers that are mostly working in smaller more nimble organisations than Server customers. Plus Atlassian change their perspective, too by learning that it is a good idea to make it configurable who can edit these configurations.

So great of you that you openly changed your perspective to see these new features with different eyes. You're a real rock star of this community.