Created 21 years ago. Unassigned and the last update was 8 years ago. This represents Atlassian more than anything. 

Addin my Vote - We need to create a Project for each new Client. I should not need to give my Project Managers Admin rights to the entire system, to do this basic task.

Hi, in case you are up for a third party solution that's hosted by Atlassian.

Project Templates for Jira offers an intuitive way to design custom project templates and allow non-admins to create Jira projects based on them.

• Customize the templates configuration to meet your unique requirements

• Give non-admins template specific project creation power 

• Customize the UX & information displayed to non-admins 

• Clone and predefine project versions, components, project role actors and issues including their hierarchy.

• Avoid the technical debt of unnecessary created Jira schemes/configurations

The app is built on Forge with no data egress, no sensible information stored and completely hosted in Atlassian's cloud infrastructure. 
Please let our support know if you have any questions.

@Derek Fields, I need these people to create projects which is why I'm complaining about it on this Jira Cloud issue thread about granular permissions to create projects. We usually have ten to fifteen new jobs a month and the Jira projects associated with them are created by their project manager or controls engineer. Right now that means every PM and controls engineer has to be a Jira administrator. My company is unable and unwilling to create a central Jira authority, right now it's just me trying to convince people to stop using post-it notes and I'm too busy to go around creating everyone's project for them.

@Roberto Ialino, archiving projects is a feature of Jira Cloud Premium which is double the cost of Standard. Using permissions to hide old projects works, but only for people that aren't Administrators, but right now everyone that cares is an administrator, so we can't actually hide these things.

Hi @Derek Fileds for instances with 2k users you need a certain number of administrators since UNFORTUNATELLY the admin permission are not granular enough.
On large organization you cannot apply adminin permission for create new project (for example) because the same permission enable the user management. This have completely no sense expecially now that there is an increase of security requirements.
Atlassian NEED TO DO SOMETHING since this administration model does not work at all.

@IBrown_BluePrint - if you create a permission schema ad hoc that restrict to only some people the visibility (only admins for example), you can archive projects.
About the cost you are mentioning is not clear to me at all.

Best regards

@IBrown_BluePrint - Do you really need 20 Jira administrators? In my experience, even the largest organizations can usually get by with 2-3 Jira administrators. When I see that number of admins, it makes me wonder whether there are too many cooks in the kitchen. It makes me shudder to think that they are "un-savvy enough to ..." Why would you give people who don't know what they are doing Jira admin permission?

I talked my manufacturing company to move to Jira from literal post-it notes and it's junk like this that is getting me tons of pushback. I now have 20 Jira administrators, most of which are un-savvy enough to delete the entire site if they got lost enough, just so they can create projects.

The real kick in the pants is we've already got multiple pages of projects in less than a year and we'd have to literally pay double the price to unlock the ability to archive them. Can't hide them with restrictive permissions either because everyone has to be a damn admin to create new projects!

Sad!

This isn't going to get implemented in any of our lifetimes. :')

High priority for 6 years.

These kinds of "issues" that stay without an update for years despite increasing number of support requests makes me want to migrate away to a solution like ClickUp.

My suggestion is to solve it with some plugin 

WOW!

This issue has 18 years!! It can now has a definitive Driver´s License.
We still need to grant a high level permission to people that just need the ability to create classic projects (the name was changed to Company-managed now).
Anyone from Atlassian is monitoring this??

I just realized that this issue - `JIRACLOUD-1431` – turned eighteen years old on March 12th of this year.  This issue is now old enough to vote!  Congratulations, this issue.

I first comment on this issue in 2007, when this issue was only four years old.  Occasionally, I get email with comments, and I like to check in on it and see how it is doing.

When this issue turns twenty, I think all us commenters should get together for a party!

https://getsupport.atlassian.com/browse/JST-640337

To find out that this is not a new issue but is years old is disheartening. Requiring admin rights for project creation is just brain dead design.

@Patrick Peak and @All,
As some users have mentioned, permission rules seem to need an overhaul. I myself have experienced limitations or inconsistencies between rules despite the depth of customization available. I don't believe permissions should ever have conflicts. If your permission structure is sound it should simply notify a user / admin when access cannot be granted and why.

Administrator access at the project level tends to be a common request.

I tend to like the idea of defining reusable but customizable settings like:

1. Roles: defines what a user can do (account admin, project admin, manager, contributor, member, etcetera)
2. Groups: defines what users can access (Jira instance, company, department, team, etcetera)

In this scenario users are assigned roles for each group and permission schemes auto generate (no need to edit).

• Example 1: new user is a member of Jira instance
• Example 2: CFO is a member of Jira instance, manager of company, project admin of department, contributor of team(s)

As it stands Jira has:

Permissions overview "simplified explanation"

1. Permissions Schemes in projects (used to define role permissions in projects)
2. Roles in permission schemes (used to define user permissions in specific roles)
3. Groups in administration (used to define I think site wide permissions, but seems too ill-defined  / flexible)
4. Groups like "site-admin" are a bit confusing as this is more of a role classification
5. Organizations in administration > security (don't think this has much to do with permission management yet)

Also not sure if this issue is related to the following issues, so didn't want to impose they be linked to this one.

JSDSERVER-5072

JPOSERVER-1220

JPOCLOUD-1220

@Karin that is correct. Thanks!

@Barbara - Sharlyne might be referring to the option to get this working Jira server by using a plugin. We do this in our company on our Server instance with Delegated Project Creator for Jira

It allows you to set up templates for the creation of projects and to assign permissions to specific groups to then use the templates and create projects from them. Unfortunately this plugin is not available in the Cloud instance, so technically there is a way to do this on Server that is not there on Cloud, just not out of the box. Hope that helps.

@Sharlyne Tsai: this does not work on Jira Server. There the status has been set to "future considerations", which means they won't even consider it for another year, more likely year*s*.

I'm disheartened that a request since 2003 which has 2 active tickets that relate to the topic and still no solution or actively working towards a solution to this challenge. Though an update in 2016 indicates it's important yet the ticket is still only in an 'open' state. What's even more depressing is that it works in server!!! Why is the cloud behind? What is going on Atlassian??

Just realised I need to have a whole bunch of enthusiastic admins running amok in the system just to enable something as simple as creating a project? Really, this can't be right, perhaps in the early days but not now, surely!

+1 from me!

+1

This is a showstopper, all businesses need to make sure that all their user permission levels are isolated to their job description, if not they will not pass certain audits and not being able to get their InfoSec certificate.

Any updates on this? This is such a basic but important feature. Giving admin permissions to everyone who needs to create projects is simply not reasonable. 

With the recent decoupling of Software, Core and Service Desk from a licensing standpoint, this seems like it should be part-and-parcel. Is there any update since the last one from December 2016?

Hi, we like Atlassian platform but having to pay for the relevant plugin is beyond our budget for now. I vote for this role to be implemented in the standard package.

+1

We currently use Delegated Project Creator for JIRA in our in house instance and that works great. We are looking at moving onto On Demand for our Atlassian products (Confluence and JIRA Software) but the inability to separate the creation of projects from full on JIRA Administration is putting the brakes on for us. If we could have the Delegated Project Creator add on in the On Demand version or some similar functionality, where projects can be created using predefined templates only by users outside of the JIRA Administrator pool, that would be great.

Atlassian, any updates on this item?

+1

+1

+1

@Aparna: That's what I do, except I have equipped our support organization with admin privileges, so we have a dedicated team for project creation. It works well.

Aparna, yes, creating projects with shared configuration is simple.

However, I think you will find as your organization grows that you don't want to personally create every project, and that you would like to begin training additional JIRA admins so that you can do other things, like take a whole day off.

In other words, the point of this permission is to begin to create a security infrastructure that allows for delegation of duties, instead of keeping us in the current all-or-nothing structure.

I actually want to remove my +1 from this. We have recently rolled out JIRA across my organization and I had initially considered this to be a roadblock. However, it helps me to have project creation centralized as it enforces my teams use standard workflows, screens, and so on. I represent project governance at my org and this enables my team to have consistent process across all our projects. So lack of this feature has turned out to be a blessing in disguise. I do not plan to give my project managers access to be able to create their own projects for the foreseeable future. 

NOTE: I create projects using "create with shared config" feature and I have one project that has all the right settings that I use every time. the overall process of creating a project and related confluence space takes me about 10 minutes. 

+1

+1 for us too. We are a businness school based in Switzerland and we need to make "Create New Project" a separate global level permission.

You shouldn't need to be a Jira-Admin to create a project..

Pascal

Agree, we employ a project manager who needs this function without being to admin the whole JIRA on prem install

@Jacques Papper: They way we handle this is by equipping our Support Department with Administrative permissions, so that customers can ask for project creation via a designed template in the Service Desk portal. Works well.

How do current users deal with this ? It's simply unacceptable to give admin permissions to everyone who needs to create projects no ? 

+1 On need for allowing individual or a group to create their own projects.  Granting Admin access is too lax.  

Hi tracy.rhinehart,

Please see the related update on JRA-3156 from yesterday. We are working hard on both JIRA project configuration and authentication across our Cloud, Server, and Data Center products.

Regards,
Dave Meyer
Senior Product Manager, JIRA

Any update? We are having a hard time broadening the use of JIRA since we have to give users the keys to the kingdom to create projects. Not a well thought-out security model, IMO. That, in combination with no SAML authentication is making JIRA a tough sell to our security folks. It sounds like there's finally movement on the SAML front, curious about this as well.

Sorry for the duplicate comments, but when I leave a comment, it doesn't display on the JIRA ticket itself - I've now received 2 emails but can't see the comments on here, after forcing a cache refresh too.

Maybe I've just found another bug in JIRA - when you get 180+ comments on a single ticket, it stops displaying new ones. Or possibly when the length of all comments combined exceeds 65,000 character or some other value, it stops displaying new ones. Or maybe the server hamsters are just slow today.

@Dave Meyer
Any update on this? 

This is an absolute must have!! I am new to JIRA and just spent hours trying to figure out how to do this and now I see that was a waste of time.  There needs to be another layer like this for security purposes.  There is not need for a large group of the people that use this to have this much access.  It can't be that hard.  We spend thousands of dollars and what is supposed to be the leader in project management and you still haven't done this.  Very sad.

Hi Dave,

Can you please let the customers know on when this could be done. It appears that this is something atlassian plans to do but it has not been done it yet.

Can you give us some insight after you talk to actual development team (And/or Marketing team) what the real problem is to keep this very legitimate requirement from customers pending for so long.

Or, let us know some opensource add-on that can enable this functionality?

Regards,
Mona

"and I can't fathom how some people are so bent out of shape about it. It's really funny."

Says it all, really.

Since version 2.1 and still dont fixed... this is incredible... no words.

Please, increase the issue priority to critical for next releases. I think that this is a security update in your software. Some JIRA users must be able to create projects without administration privileges like at Confluence and Bitbucket.

Cheers,
Felipe.

@Dave: Thank you. Have a nice day .

I believe that Atlassian is sincere about this, so take a deep breath and let's assume that this is addressed in one of the two coming major releases.

Improving project configuration and maintenance are going to be a sustained investment for the foreseeable future (I know I reference "foreseeable future" a lot on jira.atlassian.com). We would love to move faster or have more to show at this time, but nevertheless we are extremely committed to improving this aspect of JIRA.

Dave Meyer
Senior Product Manager, JIRA

@Greg: :-D.

Yes, I am entertaining the idea that Atlassian had more important issues to prioritize for the last 13 years, and I am acknowledging the fact that Atlassian can do whatever they want with their product. Rather than focussing one minor inconvenience and unfavorable priorities, I remain focused on how great JIRA is despite its flaws. This feature is nothing more than an additional administrative burden, one I can live with if need be. It's a nice-to-have scenario, it's really not a big problem for me, and I can't fathom how some people are so bent out of shape about it. It's really funny.

If this really mean that much to you, I would refer you to the second paragraph in Atlassian's most recent update:

• "Simplifying project setup, configuration, and maintenance is one of the JIRA team's top priorities right now. We are in the early stages of a big investment in making it easier to get started with a JIRA project and maintain a large number of projects at scale.".

I believe that Atlassian is sincere about this, so take a deep breath and let's assume that this is addressed in one of the two coming major releases.

Your argument is pretty facile when they've had 13 years to implement this.

Are you seriously suggesting that over 13 years, they've always had something more important to work on, than this issue? Especially when this is basic functionality in any serious enterprise application?

Also you seem to have a myopic focus on just this issue. Yes, perhaps on this issue, they have just barely met the minimum level people would expect for responsive communication. But across the other top 30 voted issues/enhancements, they are woefully inadequate.

@Nick: When arguing against people who are cussing, cursing and shouting, it is impossible to remain civil and not be condescending. Bad language is simply not a proper way to get your point across in a public forum.

I second Peter's comment; I think Atlassian is decent at providing feedback and I would not expect them to comment twice on the same issue. And they updated the ticket in January this year. What more do you expect? If people would actually read older comments and review the ticket status, we would deal with a lot less noise.

@Nick, I don't want to be Atlassian advocate, but in this specific issue they did a pretty good job communicating their plans. The latest being from June, that's pretty clear and recent.

Dave Meyer added a comment - 14/Jun/2016 12:01 AM

As stated in the update from earlier this year, we are actively planning how to deliver this feature in a way that solves as many of the requests on this issue while still maintaining power and flexibility for the tens of thousands of customers who are using the existing permission scheme system.

Dave Meyer
JIRA Product Management

@Jon - There's no need to be condescending to people trying to have their priorities recognized. Do we know what is going on with Atlassian's backlog? No. So it's true that we can't say with certainty the nature of the fact that the top rated issues aren't getting addressed. This could be addressed if we got better communication FROM Atlassian, though.  Usually all we get is "this isn't on our roadmap", and with that little to go on, the customer base will grow more and more frustrated.

Additionally, we as customers do have the right to voice our opinions, that's the whole point of a space like this.  If Atlassian does not prioritize the things that are important to us, then it's entirely appropriate for us to voice our opinions to try to get them to recognize what we feel is a priority.

This gets to what I said in the comments of JRA-1973:  "I don’t think the discontent of the user base is going to be going down on its own without addressing these high voted basic functionality issues, or much better communication, OPEN communication, for WHY these are not being worked on. Without those I’d guess that the frustration will boil over more frequently."

Again; we don't know what's going on in Atlassians internal backlog. Could be that the UI attention covers a massive in-dept restructuring of their product, to support the future responsive web needs.

What it boils down to though is whether or not the inconveniences outweigh the benefits, and that answer is clear to me.

Good day sir.

"Everyone who been involved in development knows, that not all features are as easy to implement, as it might appear to the untrained eye."

Everyone who has been involved in development also knows, that some features are much more important than others to implement. For example, Atlassian has spent the last little while "improving" the UI of Jira, instead of doing enhancements like this.

Actually, the UI was fine and already usable. I some ways I prefer the old UI to the new one. I would much rather preferred that Atlassian work on this issue, and the other top 10 voted items, because that would deliver me value for the money my company pays. We get little to no value out of the UI changes they have made, because the old UI was fine.

Ladies and gentlemen, please.

Everyone who been involved in development knows, that not all features are as easy to implement, as it might appear to the untrained eye. Secondly; Atlassian is in full control of what the strategy for their products looks like, and perhaps this just doesn't fit the parameters of the direction Atlassian is headed in.

I have personally missed this feature ever since I started using JIRA (today I'm the product owner of JIRA in our organization), and like you I don't understand why Atlassian would promote the idea of more administrators; I mean, come on!?

That being said: I am very pleased with JIRA as an issue tracking and task management system, in fact I think it's second to none at what it does. Additionally I fully trust that Atlassian knows what they are doing, and I believe that there's a good reason for not implementing this feature. Still I hope that we'll move past this obstacle in some way or another, soon.

If anyone would like to know how I manage this inconvenience, please feel free to contact me.

I couldn't agree more.

I think this features is quite basic! Who wants to put all the world admin... come on !

Maybe someone needs to let Mike know. Agree. I realize this is "just" a product feature request but if it's been open for 13 years....maybe Atlassian hopes everyone will give up asking.

WTF. THIS ISSUE IS OPEN SINCE 2003! Wow. Shocking. How many employees does Atlassian have working on jira? This is rediculous.

I would also like this feature. This is a currently a big gap in the way I would like to use this software at my company.

In our case, is very important to have this funcionality available, so I give +1 to the proposal.

+1 on this feature. It would take a big load off the admin group for us.

@Dave Meyer

Any status update on a planned release timeframe? The Delegated Project Creator doesn't work for us because the mail server rejects the mail being created by it and the default JIRA API for it doesn't allow the add-in to create e-mails in a format that the mail server will accept. We are stuck right now. https://wittified.atlassian.net/browse/PCFJ-210

Thanks

@Dave Meyer: +10000! We trust in you Dave! Regards from Bcn

@Dave Meyer: +1

As stated in the update from earlier this year, we are actively planning how to deliver this feature in a way that solves as many of the requests on this issue while still maintaining power and flexibility for the tens of thousands of customers who are using the existing permission scheme system.

Dave Meyer
JIRA Product Management

What you surely meant to say is that the lack of the feature is by inherently poor design for something that is allegedly commercial grade software for which I do hold Atlassian responsible. If you take a look at the last comment on this ticket, which is my comment, and you'll understand why I say that. That ticket was closed after being open for years. Atlassian don't want to fix it or anything else related to permission sets - as the evidence shows (and some of the other linked tickets that have been closed indicate too). The entire permission scheme is woefully inadequate. In order to manage users you have to be an admin. This is dangerous. Giving people the keys to the kingdom when they only need to manage users is a recipe for disaster.

This functionality would be nice but we can't blame Atlassian for interrupting our individual business capability, when the feature (or lack thereof) is by design. We are modifying our processes to match the options in JIRA, and it's really not that big a deal. Alternatively there's always the Project Creator plugin.

+1. We held a meeting recently about how JIRA is now actively harming what we do as a business for myriad reasons. We are actively looking at alternatives.

+1 from me as well. Our PM's require this functionality, but we don't want to have a bunch of Admins. Not having this puts us in quite a bind.

I tried installing this (Standalone Project Template v 1.1.1) for it says it is for versions 7.0.0 - 7.1.5 . But, it is not compatible with our version (which is 7.1.1) so I have removed it.

We would like to see new permission added - too many admins.

I appreciate that Jira wishes to look a holistic solutions but being able to grant create/edit/view only type rights is a basic requirement of any "enterprise" solution. While the issue of fine grain permissions and how they are managed may well require a holistic view and involve much review and debate etc. the basics should already be covered and it is concerning that they are not. I will also note that this ticket was opened in 2003, which means that it has taken over a decade for what is a relatively basic feature of security permissions to reach JIRAs to do list?

@Normand Carbonneau +1 - exactly. This should absolutely be an out-of-the-box capability. Plugins should not be required to achieve this. But we already knew that. That's why we're all over this ticket.

Hi Raul, no problem. What I am trying to explain is that even if a plugin is free, I will never use it. We are talking about a feature that I am expecting as an out of the box feature for a professional product. Using a plugin means a high risk of incompatibilities with future updates on the cloud. I want this feature delivered and supported by Atlassian. Especially when dealing with security.

I want to push my plugins to the CLOUD... but Atlassian don't wants to "verify" me because I don't make PAID addons, my addons are FREE..
Sorry @Normad Carboneau and @Gary Mellor... I am only trying to find a solution for this request... :_(

ATLASSIAN PEOPLE ¿¿¿WHERE ARE YOU???

Raul, what about CLOUD users? We are paying A LOT of money annually and this is the reason why we are complaining. Third party plugins is NOT an option.

Giving individuals site-admin permission so that they can create projects having been on a (internal / external) course and having taken an exam is not a solution by any measure. It simply highlights how farcical it is that JIRA does not already have this basic permission (along with a good many others beyond the scope of this ticket). Your 'solution' means people have access to the system beyond their needs so they can do something very simple. It is also expensive as a 'solution' since it means they either need to be sent to an external training course (costs involved and loss of productivity) or be put on an internal training course (cheaper but an increased loss in productivity since more people are involved: someone who already knows JIRA within the company training those who don't). While it 'solves' the problem (people can now create projects) it has taken training courses, cost money and personal productivity, we still have the same end result: taking a hammer to crack a nutshell and we still have people with permissions well beyond what they require. So, in fact, your solution is not a solution, it's asking for trouble as those same individuals can still wreck the system either deliberately or inadvertently. Here is all we're asking for here:

Use case: As a JIRA administrator I want to assign a Create Project permission to an end user so that they can create their own projects.

Job done.

The plugin is: https://marketplace.atlassian.com/plugins/com.rauliki.standaloneProjectTemplate.StandaloneProjectTemplate/server/overview

The source of my plugin:
https://jirasupport.wordpress.com/2015/12/18/tutorial-creating-a-project-template-with-standalone-artifacts-in-jira-7/

In my company, we have "homologate" a few people (Agile Coaches) through a JIRA Project Admin course and a validation exam.
Now they are "site-admins" (not system-admins).. and yes, they have the "keys" of the kingdom...

The first time, they make mistakes ( changing shared worklows as they want without talk with the responsibles of the other projects, etc..), for this reason is important to make a validation exam. Otherwise I have created a plugin of a "project template" to allow the Agile Coaches create new independent projects (with independent scheme, field config, permissions, workflows, ...) it's a little bit inefficient, but is the solution

Regards

Yes.... I think we can try (or Atlassian) to "talk" with the company of this plugin to homologate for cloud.... it's only an idea

@Raul Pelaez, that is for server only. It also assumes that the user wishes to use pre-defined templates. I simply need to delegate a permission to end-users, such as Team Leads, Project Leads, Product Managers etc., that will allow them to create their own projects howsoever they choose and without having to give them 'the keys to the kingdom' to have them achieve it. Simple.

Hi @Gary Mellor, the plugin is the "Delegated Project Creator" .. I think it works on Datacenter and It's Atlassian verified...
https://jirasupport.wordpress.com/2016/02/01/delegated-project-creator-for-jira-addon/

"The Delegated Project Creator for JIRA add-on allows JIRA administrators to create templates of the schemes needed for commonly used project configurations. Create as many different templates as you need to handle new project requests.

Then, identify the trusted groups who can create projects from those templates, or request projects. Those trusted group members can then do self-service of your routine project requests, freeing up your JIRA Administrators for more important work!

A history is maintained of all project requests, collecting valuable information about who requested a project and why."

@Raul Pelaez: And I'm very happy for you. Is that plugin available in the cloud as well server version? If so, what is its name because it seems that the availability of it has somehow escaped the attention of all the voters and watchers on this issue. For years.

It's very easy to know why Atlassian don't want to do this change... BECAUSE there is a PLUGIN that do exactly this. And the JIRA ECOSYSTEM is important TOO.
JIRA must be a SIMPLE issue tracker by default and if we need some EXTRA functionalities, we can use the PLUGINS. For me It's a PERFECT great tool!

Regards

Product management must follow the priorities set by the company. The priority of Atlassian in the last few years has shifted, from delighting its base of technical users with unprecedented value, to growth in adjacent markets: sell to product management teams, digital marketing companies etc.
In the previous years it would have been impossible to compete with Atlassian offerings. Now new space is opening up for competitors. I will not name anyone, but personally after 9 years and multiple products, am now close to buying something from a competitor.

Gary, you have it totally right. The most frustrating part for me is to see Atlassian putting thousands of hours of effort on so many things that are useless for most of us (bells and whistles), and still seeing fundamental things like that ignored. I have been a strong advocate for JIRA and Confluence over the years, but even the most convinced people like me are starting to have doubts. We are actually in the process of evaluating another software... This would be totally impossible for us to act like this with our customers. We would no longer be in business for sure.

We had a similar problem where historic issues got snowed under other priorities. We solved it by having a couple engineers devoted to clean them up, one after the other. In a couple of months they were able to clean out most of them - except for a couple which required a too heavy refactoring. The cost of this investment outweighed the bad buzz in the field about our responsiveness and customer focus.

Francis

@Dave Meyer.

RE: your post in this thread on 04/Jan/2016:

----------

"...The ability to create new projects without full JIRA administrator permission is one of the initial areas we will investigate, so this is a high priority for our team. While we cannot provide any information on a planned solution or release date, we will update this issue as we progress..."

...and my comment yesterday:

"...we can expect to wait approximately another three years for a further cut 'n' paste update from whoever the Product Manager happens to be at that time...."

----------

Thank you for your reply, which provided some clarity to this discussion. What I think all the voters and watchers on much needed fundamental features such as this can take away from this is that while your comment, referenced above, was honest, my comment was accurate.

The first of the twelve principles that comprise the Agile Manifesto is:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Perhaps you could also provide some clarity on the point at which Atlassian lost sight of this? I am not specifically referencing this ticket when I say that either nor am I deliberately trying to be inflammatory.

Regarding your specific point yesterday: "...I would wager this is the same for any product development team at any growing software company practicing agile development..."

My employer is going through growing pains as it emerges from start-up mode and is maturing everything it does. Where I work the customer is King. If they need a feature to improve their UX or add value to what they do then that is added as a higher priority on our roadmap than, for example, pretty UI changes. It doesn't get to the point that the customer threatens to leave us after we haven't implemented it years after they originally asked for it. JIRA has been doing this for years.

Perhaps the difference here is that the voters and watchers on not just this issue but other much-needed, basic features, is in the nomenclature: Atlassian are practising Agile development while they're actually delivering it.

There are a myriad other such tickets where the voters and watchers are over a thousand in some cases and the ticket has been open for years with people, like me, complaining bitterly at the lack of updates or that they have, in fact, been closed as Won't Fix.

Dave, customers who are consistently failed by a business usually stop giving them their custom, it is just a matter of time.

Furthermore, to address your specific claim that "...We review and update all highly-voted feature requests on a regular basis...", I believe the facts on this ticket alone speak for themselves:

Therefore your assertion would seem to be somewhat adrift of the reality here. Over five years before the first update as far as I can tell and then another gap of almost three years. I guess 'regular basis' and 'highly-voted' are subjective terms. It seems that Atlassian considers updates years apart to constitute 'regular basis' and that, at the time of writing, 531 voters and 273 watchers (ignoring all the frustrated commenters) does not amount to 'highly-voted' or am I incorrect in my conclusions here?

Hi gary.mellor,

We review and update all highly-voted feature requests on a regular basis because we think it's important to give our customers a recent and honest assessment of the status of a feature request, even if that status has not changed. The reality is that we will only be able to address a small fraction of all the open feature requests at a given time, so the vast majority will not see a change in status. We absolutely recognize that this is frustrating and disappointing, but being honest about the status is important to us, even when the news is usually not good.

Let me be perfectly clear: when Roy said that it was a feature we wanted to take a look at in the near future, this was accurate. We were considering it at the time, but ultimately we focused on other priorities and were not able to address it then. When we update issues, we make an effort to provide an honest assessment about the knowledge we have at the time, but this isn't the same as a guarantee. We continuously re-evaluate our roadmap, priorities, and investments internally within the JIRA team as well as responding to the larger needs of Atlassian. I would wager this is the same for any product development team at any growing software company practicing agile development.

Dave Meyer
JIRA Product Management