G'day 👋🏼 I'm Jason Wong, Lead Product Manager for Jira Software Cloud, AMA

[Jason Wong]

Last month we formally announced the new Jira experience, which is a culmination of over a year of daily releases aimed to improve features, functionality, and overall value to our customers. We built this new experience in direct response to customer feedback - we heard loud and clear that our users want a way to get their projects up and running quickly, focus on the work that matters most, and move seamlessly between projects - and be able to do so in an intuitive UI. 

We're not done executing on this vision yet, and want to hear your questions about what you've seen so far. Ask me anything about the new Jira experience:

• What is it, exactly? Why? Who is it for? Does it make sense for my team?
• What are best practices?
• What's next? 

Start adding your questions to this discussion (you can add before and during our live AMA), upvote others' questions, and stay tuned as I'll be answering anything that's on your mind about the new Jira experience on Tuesday, November 13th at 2pm (Wednesday, November 14th at 9am in Sydney). Hope to see you back here then!

[Warren · Accepted solution]

The idea behind the new issue view is great, but there is a major flaw in it at the moment, to the extent that I keep needing to use the "See the old view" link. The problem is the long list of fields down the right hand side, in no particular order. I've seen large numbers of people on the Community forum complaining that the order needs to be configurable and / or bring back the tabs.

My questions are :

1. What is being done to address this?
2. What timescale can we expect to resolve this?

Until this is resolved, the new issue view is useless for many people. As an example, there is a team in my company that has ~50 fields - these appear in a random order and move around for no particular reason, so it's a nightmare to try and find a specific field.

Thank you for your time

[JJ]

100% agree with this one. Because of these limitations of the new issue view, I cannot transition my teams to the new Jira isue view. 

[David Hudson]

I agree as well. I have to revert to "See the old view" on every single task I try and manage. 

[G V Shabareesh]

How to Create Scrum Project using rest api from python.

def creating_project(self):
pro = self.jira.create_project(name='BiggBos',key='DB',template_name='Bug tracking')
print pro

it is creating a bug tracking project. 

where as i have to create a scrum project like this. but i am getting an error. 

please resolve my issue..

Thank U...

[Jason Wong]

Hi @Warren,

This is a great question and I'm happy to share some insight into this!

The 'new issue view' has been built to be native for next-gen projects and so for those project types it cannot be disabled. For next-gen projects, you can already customise the layout of the right hand side of the new issue view. To do this go to project settings → issue types and dragging the fields up and down to order them.

For classic projects, we still need to map to the new issue view to classic configuration settings. You'll be pleased to hear that we are releasing the capability to order your fields on classic software project when using the new issue view - we'll start rolling this out within the next month! You will be able to order fields on a per project → per issue type level and will control the layout of the fields on the right-hand column of the new issue detail view everywhere that issue is displayed across Jira for consistency.

In the meantime, if the lack of ordering makes this unusable, there is a per-user opt out within your Personal Settings that you can use to disable the new issue view for all classic projects for the time being. 

Support for tabs will be coming shortly after that.

To address your comment on "why fields move around for no particular reason". 

• With the new issue detail view, there is no 'edit form', which previously would allow you to edit fields that did not appear on the view issue screen until there was a value. We heard a ton of feedback that this was very difficult to understand and use.
• Now, all the fields for a particular project → issue type is on the right-hand column. However, we use the 'show more' option to hide fields that do not have a value yet but you can easily get to them quickly and add a value. When you do add a value, the next time you, or anyone on your team, looks at that issue, it will be visible above the 'show more'.
• On top of this, the configuration will allow you to place certain fields to always be visible, whether or not they have a value. These may be important fields to always have up front.

[David Hall]

Hi Jason, in reviewing this response regarding classic projects, it seems you are proposing solutions to the new layout to provide different approaches to existing functionality.  For example, "Screens" as we have established them are completely ignored in the new issue view.  Providing a new solution to fit the new issue view, especially when you eventually remove the ability to disable the view (because we all know that day will come) will mean that we will have to completely re-engineer the structure we had in place.  I am hoping that you can provide some assurance that the shift to the new view will provide a means to port our existing structures over, or better yet an option where I don't have to do anything to maintain existing functionality, versus having to rebuild.

[Jason Wong]

Hi @David Hall,

For Classic projects, you will find that most of the new view issue will be backwards compatible. The screens will still pop in the same way. What will change however is the layout of the data on the screen.

Can you tell me what specific screens are missing that you configured and expected to see on the new issue view that aren't working?

[Nilesh Patel]

Hi @Jason Wong,

It appears there is a regression that has happen with regards to usage of custom fields here https://jira.atlassian.com/browse/JSWCLOUD-17272 which does not allow for custom field to be visible after they are configured.

Therefore you proposal (above)for custom fields cannot be used until we get JSWCLOUD-17272 deployed to customers.

 For next-gen projects, you can already customise the layout of the right hand side of the new issue view. To do this go to project settings → issue types and dragging the fields up and down to order them. 

I know the team is working on this and hopefully this is resolved today.
Note, this is impacting my ability to get Next-gen jira projects sold as a product to use at our organization and migrate from Classic Jira. 

Thanks.

[David Hall]

Hi @Jason Wong, while I am expanding on your question, here is a list of missing functionalities in the new view, which prompt our team to have to go back to the original view every time:  (Note that the first three directly answer your question tied to the Screen administration.)

1. A single-view “Edit” mode, which allows a single point of modification for the full issue vs. individual modifications, and reduces notifications down to one single notification of the changes, no longer exists.
2. Both in the view itself, as well as the aforementioned “Edit” mode, all administrative settings around Screens and Screen schemes are lost. This includes layouts of the fields as we desire to see them (not the “everything simplified on the right”) as well as tabbed breakdowns of the field information.  Note that some of our fields are text-based where we can enter paragraphs of information, and this does not display well on the right side of the screen.  We also have established a top-down prioritization of the field information provided on the issue, whereas the new View mode has a self-determining mode that is pushing key fields down into the lower section of the right panel while moving fields we care much less about towards the top.
3. Adding sub-task items from the issue also ignore the Screen and Screen schemes. Instead of being able to enter full information, the new view allows only an entry of a summary, and then you have to open the issue to try to fill in the rest of the information.  (Extra UI steps.)
4. Hyperlinks provided in fields merely display as text in the new mode, where they are useful, active links in the original view.
5. The ability to order comments and history in ascending or descending mode is not available. The most recent information is buried at the bottom of the list, requiring in some cases a lot of scrolling to get to the most recent information.
6. While providing Comments and History, the All and Activity views are not displayed. This helps us to see the timing of comments provided in the issue to the changes being made on the issue.
7. Confluence links are not provided in the new view at all.
8. The attachments section in the new view is vastly simplified (read: not as useful) compared to the original view mode. The ability to view the images in list form and order them by preference (Name or Date, Ascending or Descending) provided valuable options if an issue had a larger set of attachments included.  In the new view, these just take up a lot of space and require a little more hunting.
9. The ability to manage watchers aside from one’s self is missing. This was useful not only to ensure notifications were going to the necessary individuals (vs. having to at times make a larger number of mentions), but also to verify who is getting notifications.  (Administrative verification when users report not receiving notifications is more challenging as well when I can’t see who is included as a watcher.)
10. The ability to transition issues between standard issue types and sub-task types, in the form of “Convert to sub-task” / ”Convert to issue” is missing.  We use this feature often.
11. To a much lesser degree, the View Workflow mode, which we have had to use on occasion, is missing.

These are the things that we are using that are missing.  There are additional features I've seen that are also not included, though it makes me reluctant to explore theses additional features as needed.

My biggest concern with these missing features is that we are actually exploring having to completely rebuild our approach to how we use JIRA, not because we want to but because it feels like we are being channeled in that direction.  Existing UI to open an issue and get to the original view (three separate clicks, and that is until you refresh which then forces you back to the new view), is causing much grumbling from my users around how they feel about JIRA.  And while I can instruct users on how to turn this view off, I strongly suspect that the day is going to come when this is no longer an option.

[Warren]

Hi@Jason Wong

Another request. On a Next-Gen board, when I've clicked on an item, the pop-up view has opened and then been closed, that item on the board hasn't been highlighted (i.e. it doesn't have focus and is not listed in the URL &selectedIssue=).

Could this seemingly simple functionality please be added to the classic boards as well??

A use-case for this on classic boards : I click on the top item in a column, the pop-up opens. I change the status so it will appear in the next column. When I close the pop-up, the focus is still on that item, which now is bottom of the next column (potentially 20 or 30 items down!) - not where I want to be. I then have to click into the URL and remove the &selectedIssue= to get the display back to how I want it - very frustrating.

Thanks

[Dave]

Consider the user who moves an issue from A to B then wants to move the same issue from B to C, or re-rank it relative to its new column. I'd argue that keeping focus on the issue is a useful feature which is missing from the next-gen boards.

[Warren]

Surely if you want to move an item from A to B and then from B to C, you would do it all with the pop-up view open, in one go? The new UI has enabled a really easy status change mechanism

[Walter Buggenhout · Accepted solution]

I believe that the goal to 'get people started quickly and easily' with their project is certainly being met. But on the other hand, I have some serious doubt about the 'moving seamlessly between projects' ambition.

As each team is free to configure its own project to their liking:

• how should we deal with cross-project searching and reporting?
• how should we make sure that we collaborate and not end up in a bunch of isolated silos on a per project basis?
• supposing that most teams manage more than 1 single project simultaneously, how do we easily give them access to all their work in a single view?

In close relation to that last point, how would you define a 'project'? I am aware that the same challenge applies to Jira Server and Cloud (as it was) and Data Center too, but if a fully project centered approach becomes the standard, separating the configuration makes this a potentially bigger risk in my opinion.

[Ory Zaidenvorm]

Totally agree!

[Francis Kus]

This is also my greatest concern with next-gen projects...

[Jason Wong]

Hi @Walter Buggenhout,

Thanks for your feedback. We plan to introduce the notion of templates that will allow multiple projects to share configuration like IssueTypes, custom fields, notifications, workflows etc.

We also see a lot of teams who work across a number of other teams / projects and so we will also be providing cross-project views to those teams.

Next-gen projects have completely rebuilt configuration and so we've started simple by going project centric, before expanding into more advanced cross project use cases that introduced added complexity in implementation, say due to a board having cards that derive configuration from different projects. We'll get there though, so please watch this space!

[Walter Buggenhout]

Hi @Jason Wong,

Thank you for your reply and the openness throughout this AMA. If I may try to rephrase, next-gen is much more than a design exercise, but really a total refactoring of Jira as a whole.

I understand that we are in a pretty early stage of the rebuild. And if I want to work in separate, isolated projects and consider myself an early adopter, now is the time to start experimenting with next-gen as it is the direction for the future. By participating and giving early feedback, I can contribute to the direction of the product.

If I need cross-project backlog management and overview, I get the idea that is too soon to get on board and rather stay on classic projects for the time being.

If that assumption is correct, how long do you expect it to take before the actual cross-project capabilities will start to take shape and evolve into the mature functionality I need as a team lead in terms of visibility, reporting and so on? I would like to avoid having half my organisation running and configuring old style projects while the other half is going next-gen. I am somewhat concerned that this would rather increase overall complexity for managing the instance as a whole.

[Jason Wong]

Hi @Walter Buggenhout,

Yes, thanks for understanding. That's exactly where we are now with advice on when to use next-gen projects, vs expected future capabilities.

I can't give a timeframe on the cross-project views at the moment other than to say that it is further out than the items you see on the public roadmap.

For the time being, have you tried using a Classic board?

The Classic board is not restricted to Classic projects. It is capable of running across all projects because it will pull in any issues that result from the custom filter you build, including issues from next-gen projects.

[Walter Buggenhout]

Thanks for the confirmation, @Jason Wong. 

I use classic boards on Jira Server / Data Center all the time. My audience consists of teams. And teams, by default, are most of the time working on items in different locations. Some of it is planned, some of it is not. Some is related to customers, other work is internal.

Yes, I do run into the occasional product team that is doing work around one single project or product. But then it usually is a huge project. 90% of the time, what I need is a team board instead of a project or personal board. Although I understand 100% that it is way easier to create a graphical board to represent the different stages of your work than configuring tons of schemes, it feels to me that forcing the connection to a project in order to do so is still built on a technical cornerstone of Jira: a project, the container you need to have in order to store your issues.

Suppose there was a team concept in Jira. Where you could specify the flow for your team. And then associate a board with that. And then add projects to your board ...

[Jack Brickey · Accepted solution]

A number of people in the Community is asking about Next-gen and Roadmaps for Server. Any discussion about that possibility?

[Sarah Elkins]

I am also interested in this question.  We currently host a large Jira Software Server Datacenter inside our company firewalls and would like to know if and when these features will be coming to that offering.  

[Elke Heinrichs]

I llove the Next-gen features and the Roadmaps. Due to the fact, that we run a large server instance too, i also want to know if and when this features make their way to the Server Version of Jira. 

[Koen Vermeulen]

I'm curious too! If Next-Gen is available for Server, when will the update take place?

[Daniel Fietta]

This was mentioned in the webinar yesterday: Currently they have no plans for bringing this feature to the server version.

[Abel Lineberger]

If y'all are primarily interested in the Roadmaps functionality, I highly suggest you investigate Atlassian's Portfolio for Jira, which is a much deeper and tighter integration for intra- and inter-project roadmaps.  

It is also a fairly mature product.

[Jason Wong]

Hi @Jack Brickey,

Thanks for this question- it's one we've been hearing a lot over the last few weeks. We are working very closely with the Jira Server team to learn from customer feedback on the new Cloud features, and which may make sense to build in Server. While we can't promise when (or if) specific features will be deployed in JIra Server, we'll be balancing which elements of the Cloud experience would be most valuable with our other priorities around performance, admin control, and team productivity.

[Mauricio GALVEZ]

Glad someone mention this.. There is few or almost nothing related with features on next-gen product, specifically related with server.

[M M · Accepted solution]

How i can create ticket  and automate ticket creation for build issues in jenkins? thank you in advance. 

[Jason Wong]

Hi @M M,

You can use our Jira APIs to automatically create issues and use that with other applications.

However, if you are looking for something easier for Jira to provide, such as automations that would have a different answer. 

Would you like to have a chat directly with our team?

We would love to know more about what you are trying to do and how we can help make that possible

[Nilesh Patel]

@Jason Wong 
I would be interested as well in knowing how to call the Jira API?
Where can we find documentation on the Jira API?
Also does this Jira API work with Next-gen Jira projects?

[Warren]

Hi @Nilesh Patel

The documentation for the API is here.

I haven't used the Next-Gen projects, so can't say yet whether you can use it for them, but it works really well for classic projects. I've just tried an API call on a Next-Gen project and it does return data, but that's not to say that every API call will work

[Nilesh Patel]

@Warren Thanks for the link

Would be nice to get confirmation that the Jira API is supported 100% for Next-gen projects as well.

[Jack Brickey · Accepted solution]

Is there a good definition of 'New Jira 2.0' and what is includes. Most questions here deal with Next-gen projects but some deal w/ the new look&feel UI that is presented currently if Jira-labs is enabled. I think there is a need for clear terminology and definitions to help control the confusion people are feeling.

[Jason Wong]

Hi @Jack Brickey,

New Jira has a lot of updates and so I can understand your confusion around the various Jira brands and differentiating what is what. 

The "New Jira 2.0" encompasses the new next-gen project experience and the refreshed look and feel. We have been releasing the new features and UI over the past several months and will continue to do so as quickly as we can.

When we think about the Next-Gen project experience, these are the key new features:

• Roadmaps 
• Customizable, drag-and-drop boards
• Project-level configuration
• Redesigned issue view
• Improved mobile app 

Check out this page for more details about each feature: https://www.atlassian.com/software/jira/whats-new

[Andrew Cato]

How can I migrate my existing "classic" projects to the new "next-gen" projects?

Would love to use the new features, but if we can't migrate existing projects I don't understand how this is ever going to be used in my organization.

[Alex Galvan]

Hey Andrew, 

It is my understanding that it won't be possible to migrate classic projects to the new ones :/ 

[Nilesh Patel]

Andrew,
Think you can use the Bulk change feature to migrate tickets from one old project to a new Jira Next-gen project. 

[G V Shabareesh]

How to Create Scrum Project using rest api from python.

def creating_project(self):
pro = self.jira.create_project(name='BiggBos',key='DB',template_name='Bug tracking')
print pro

it is creating a bug tracking project. 

where as i have to create a scrum project like this. but i am getting an error. 

please resolve my issue..

Thank U...

[Jason Wong]

Hi @[deleted],

We haven't built a great way to move from classic to next-gen projects. We're currently prioritising the build of more capabilities into next-gen, which will increase the demand for people wanting to move. We understand that many teams are super busy and so in the future we will work on a better way to reduce the friction to move to next-gen.

For now, it is a manual process. Setup your next-gen project to confirm it has all the things you need to setup the project the way your team needs it to be, and then go ahead with a bulk change operation to get your issues over.

Bulk change documentation

This bulk operation allows you to move multiple issues at the same time. The issues you're moving need to be mapped to both a project and an issue type, and in doing this, you may need to also map the status and fields of the issues. Subtasks need to be mapped, too.

1. Perform a search with the required filters to produce a list of issues.
2. Click more (•••) > Bulk Change all <n> issues.

3. Select the issues you'd like to perform the bulk operation on, and click Next.

4. Select Move Issues, and click Next.

5. Enter the requested information for the issues you're moving. 

6. Review all the changes and click Confirm. 

[Andrew Cato]

Thanks for the feedback @Jason Wong.

What do you mean by "all the things you need"? Are you referencing issue types, etc?

[Jason Wong]

@[deleted]  what I meant there is to confirm with your team that next-gen has the capabilities you need before making the move "Try before you buy".

So yes, please confirm things like the necessary issue types and their custom fields are there. If you find a missing custom field, you would want to know about that before moving over.

[Ory Zaidenvorm]

 I would also suggest saving a copy of your data before moving over (e.g. by exporting all the issues to CSV).

[Mirek]

we heard loud and clear that our users want a way to get their projects up and running quickly, focus on the work that matters most, and move seamlessly between projects - and be able to do so in an intuitive UI. 

Hi @Jason Wong

There is a BIG difference between giving permission to everyone to create projects, fields, workflows, issue types .. etc. and making life easier. Looking only at "next-gen" project which I assume are a new vision of projects in Jira and allow that I am not convinced that this is a good approach..

Simple example.. Business need 20 projects that are similar for each team. There would need around 15 similar custom fields, workflow with 7 statuses.. same group of people would be admins.. etc. and this is would be a standard for every new project also.. Could you please tell me how I can quickly create 20 projects and more with the future with same issue types, fields, permissions when using the idea of "next-gen" projects? 

Why overall there was an idea of something like "next-gen" project? Who actually requested that? Users? Users would like to see things implemented that are requested 15 years ago on JAC and have hundred/thousand of votes, not spend time on a complete new solution that do not even have ability to use sub-tasks that they need to request again. It is like going back 15 years and requesting things that were already developed and should be a standard when releasing a product. I know that we work now in Scrum now and it is better to deliver something that is working than something that is good, but minimum set of features should be there. IMHO you should improve classic way of creating projects instead of implementing a new vision.

People are learning Jira features and paying a lot of money to get certified in different applications areas (like Jira Project Administrator) and when using cloud they soon would not be able to use that knowledge because Cloud is now starting to go it own path.. with the UI, features and addons even that for cloud are completely different than on server.. not quite intuitive UI as you initially think. It is getting complicated even for experienced admins to understand the vision and get up to date with all changes.

People are starting to get confused when talking about "same product" that is called Jira. When "Cloud" idea started Server and Cloud versions was pretty similar. Most od the people though that it is just the latest version of Jira with some small administration limits hosted by Atlassian on cloud solution and that is the only difference. Now with new UI and all the changes that gap is starting to grow, people are getting more problems, need to sacrifice many things migrating, do more manually..

From the marketing and sales point of view Cloud is a great solution, but if you are are going deeper into the technical details what is possible and what are the limits adding to that addons features that are also different .. you can get really frustrated..

This is on Cloud, this is not.. this only on Server.. this on both.. madness!

And another new things called Roadmaps.. this feature could be already developed for normal type of projects.. Why it was only done for "next-gen"?

And overall I agree with many other people here that this name (next-gen) is very bad.. It looks like it is something new, great and shiny but overall it have a lot of limits like overall Cloud is still having comparing to Server solutions. You can see how many confusion is out there looking at number of questions on the Community for example.

[Jason Wong]

Hi @Mirek,

There's indeed a lot of change here and we'll work to make the changes a lot smoother and more clearly communicated.

The first thing I'd like to address is that the new features we've built into next-gen go a lot deeper than UI change. There are data model changes that means features like Roadmaps do not work on classic projects. We took the opportunity to build on a new platform design using what we've learnt from customers and optimized for Cloud, for instance reliability and performance improvements have been a big benefit.

Next-gen has what we call project independent configuration. A lot of admins had asked for the ability to delegate project configuration to those in the team to let them self serve and make changes faster.

We're anticipating that you'll need a way to scale and also control implementation just like with classic project schemes but in a way that is a lot easier to administrate and so we'll help you create projects that operate with the same issue types, fields, permissions - more centrally administrated - when we build templates for next-gen projects.

Most discussions I’ve had with experienced administrators have ended with a view that it is far better to get the data into Jira, and that allowing anyone to create a project and administrate it encourages the data to be put in the one place inJira, rather than have it remain scattered or hidden in various tools, documents or spreadsheets where the knowledge or data is dark and disconnected. We believe that this open approach give organizations better visibility, promoting efficiency and innovation.

Admins have then seen how this gives them the opportunity to sort out knowledge and data management in more strategic ways through developing practises and education that drives overall organisational effectiveness to the next level. 

[Mirek]

Hi @Jason Wong

Thank you for replying.. Let me continue the conversation (if I can of course :))

The first thing I'd like to address is that the new features we've built into next-gen go a lot deeper than UI change. There are data model changes that means features like Roadmaps do not work on classic projects. We took the opportunity to build on a new platform design using what we've learnt from customers and optimized for Cloud, for instance reliability and performance improvements have been a big benefit.

I understand that if you want to promote Cloud to have more users, usage and sales it means that you need to create a "light" version of JIRA. That is obvious. Standard JIRA Server added to AWS/Azure is not optimized well and you need to do a lot of request to do things that should be simple... And on cloud infrastructure of course you pay for everything (data, storage, transfer, ... ). What I do not like is that instead of building something more generic is only done for one platform (Cloud, Server or Data Center) and you still say that this is the same product.. It is starting to not be be same product. The idea is, but not the product.

Next-Gen project idea for me is Jira 2.x or even earlier when not much was possible but at that time Jira was a lot cheaper solution than now. Of course you have many things right now on your roadmap that would make soon this idea great (like templates, adding sub-tasks, import/export, sharing, workflows enhancements .. etc) .. but when? 2020? 2025? .. People need to wait again for many basic features and figure out workarounds to handle their work. They pay money every month for every user and expect to have a complete product. In addition they are starting to get lost what solution is the best for their business.

In JAC you have duplicate requests for Cloud and Server so that people could vote on.. That is a little bit affecting visibility what is important for people overall. From Jira they expect this and that .. why they need to divide between Cloud and Server all the time and see that something is implemented for Server, but not Cloud and vice versa and wait another few years to see this in a different platform. Some basic features should be the standard when releasing even if implementation time is different for every platform. It is like serving food for everyone in a good restaurant that are sitting at the same table.. not dish by dish so that everyone is eating at different time and other hungry are just looking. It is a matter of professional approach to the customer and serving at once!

Please remember that when designing all new feature to be flexible and delivered on all platforms. The implementation on Cloud could be the light version but the experience (features available) should be the same on all platforms. So no matter which version and platform of Jira you use you get the same features and ideas. That is starting to get lost somewhere..

A lot of admins had asked for the ability to delegate project configuration to those in the team to let them self serve and make changes faster.

By saying a lot of "admins had asked" it does not quite follow my feeling. I am a experienced admin and I do not feel that many people asked for that kind of "new features". I am working for almost 10 years on Atlassian products support and here on community I know what is the level of people knowledge, what they want to get from a project and what I personally want as a admin that would speed up my work to give them a good working project without asking ton of basic questions on community that they should find easily in documentation. That is all about self serving. It just does not work and would not work until product itself would be really intuitive. And just a proof of that I see a big increase of questions asked about next-get project. There are many limitations, documentation is poor and instead of improving experience it is on the same or even worse level. If people are asking many questions about a feature that is really simple this mean that there is a big need for something better or they still cannot easily (or fully) use the product or product have many limitations and bugs that are nor fixed in a expected time. For example they cannot even do a basic thing like migrating easily from classic to next-gen and back if they do not like them ..

Most discussions I’ve had with experienced administrators (...) We believe that this open approach give organizations better visibility, promoting efficiency and innovation.

Open approach is good but where is the "stop" sign? What would be the next level that is promoting efficiency and innovation. Giving to normal users ability to install marketplace addons so that they can extend their products easier and faster?

Admins have then seen how this gives them the opportunity to sort out knowledge and data management in more strategic ways through developing practises and education that drives overall organisational effectiveness to the next level. 

I would like to underline here that we have System, Application, Project and even Board admins in Jira.. We should know about which "admins" we are talking about since every group have different needs, visions and knowledge.

For experienced project admins it is mostly true that are asking for more permission than only viewing the schemes in Jira. But on the other hand they do not care that for example number of custom fields are the most affecting performance in Jira. So if we could now give permission to create custom fields by project admins it might end up with thousand of fields, lot of duplicates, lower performance and overall a big mess in Jira instance that was until now properly managed and optimized by small group of certified admins that create projects in minutes.

If you have a big organization with thousand of users (that mostly have some standards of creating a projects and managing them) and want to still be open you might end up as admin with ongoing cleanup of unwanted projects, custom fields and other objects.. The additional problem is that in Jira there are no existing or new tools (except the new Custom Field Optimizer -> for DataCenter platform only again!) that can help admins administer Jira in easy and quick way. Instead helping admins in that way I feel that they would get more "non admin" work and spend much more time explaining to users what they can instead of doing that for them based on requirements. This is not quite the "next level".

[Nilesh Patel]

@Jason Wong There are a lot of good points that @Mirek is making. 
There does seem to be a lack of consistency. 
It would nice to be able to have a away to transition easily from Classic Jira Cloud to Next-Gen Jira Cloud, a simple example is that we cannot link issues between Classic and Next Gen Epics (with Stories and Bugs)  having this allows us slowly move from Classic to Next-gen. Otherwise it is an all nothing choice that we are left with. 
Currently there appear to be many key features missing a regressions of features already deployed such as custom field not even being visible.

So providing a detailed roadmap will allow your customers to help determine when to make the transistion from Classic to Next-gen.

Thank you.

[Jason Wong]

Hi @Mirek and @Nilesh Patel,

I hear you on the confusion and disappointment that these features are still TBD for Server and not released at the same time and so I'd like to try and explain what's going on there. 

Prior to 2017 the code base for Server and Cloud were the same and so development was carried out in lock-step. We knew that if we stuck with that path, next-gen would take a lot longer to launch as well as complete going forward. This is the primary reason why next-gen isn't being shipped to both Cloud and Server at the same time.

We are without doubt developing next-gen a lot faster by doing it Cloud first and Cloud only, with TBD for Server. The Server product will be looking to see how much traction these Cloud features get and then be making a decision as to whether to bring it to Server. This does however create disparity in features. I might however, add that within Server itself, this problem has always existed due to not everyone being on the same version. We're still on the journey of improving how we communicate the differences and also how to help make the move. 

Next-gen has been is released on top of existing functionality in Classic projects. You are still in control and can continue to use Classic without next-gen. We haven't taken away any functionality. 

Hope that makes sense. We still have a lot more features to deliver with next-gen. It's not only going to be a new lightweight Jira. It's designed to cater for a wider range of tracking needs, from the simplest through to the most advanced. We've yet to get to the advanced features, but have a big roadmap ahead and it's better we put it in front of you and have this conversation with you now as we develop it out.

[Jason Wong]

@Mirek - I didn't cover your performance concern...

The product has been rearchitected for Cloud and performance is a big area we are investing in. We have setup a performance index for top used features, and have already achieved a 25% improvement on our performance index metrics. 

One of the highlights has been a 40% faster issue load time.

Scale is also a theme on Cloud. This year we increased Cloud capacity from 2,000 to 5,000.

For next-gen to work, the creation of lots of projects and independent issue types, workflows and custom fields cannot impact performance like that of Classic projects. So you can be assured that we'll have to hold ourselves to making next-gen performant in order to make it an enjoyable experience for end-users and admins.

[Mirek]

Hi @Jason Wong,

For me this is like reinventing the wheel but pretty more expensive than the previous version.. I remember "JIRA" limits 10 years ago and maybe not you directly but a different team also started a journey of improving performance, announcing that Jira is able to handle well 100k issues, then 200k.. then half a milion .. etc. and then new features came up to the stage .. and Server was not enough so we have Data Center and also Cloud.. etc. and the story continues...

Looking at Cloud currently you are exactly at the same point. And the problem is that you would end up exactly in the same place. Next-Gen project type would give you a little bit more breath and performance improvements so that you can deploy more instances on cloud infrastructure and paying less for it, but at the end users would request the same exact features like they had before. They need schemes (or templates as you name them), sub-tasks, components, worfklow validators, required fields, story points, reports, versions, epics, epic colors.. etc. wow! .. the list is so huge. You are in the very beginning. That would take years od development, frustrations and additional confusion. People have really problems with getting all those things together. They do not know what is possible in which type of project, how to migrate from one side to another, who can create what.. why something is showing/why not, .. etc.

This whole confusion started when Atlassian decided to break down Jira to Software, Core and Service Desk .. then for example suddenly everyone realized that Kanban is not used only by software teams.. then we have Cloud versions of the same products (by name but not features and UI anymore) and now we also have differences in even Cloud project types. So we are starting to end up with a product called "Jira" but the truth is that all platforms starting to have many differences and people are starting to get lost.

Until you continue to not plan to release a new feature for all platforms in similar time (without saying "The Server product will be looking to see how much traction these Cloud features get and then be making a decision as to whether to bring it to Server.") then this would introduce whole confusion and you would need to spend so much energy to communicate and announce new features. 

You cannot build new features only for specific platforms and now also for specific project types (like Roadmaps only for next-gen). Over the years people are waiting for many features and suddenly there is an announcement that it would be only for Cloud, or DataCenter.. not for other platforms.. that they need to wait longer it is "not on the roadmap for upcomming X months". That is super frustrating. You can see how people react on keynotes at summit now and few years back.. There not so big applause anymore. I am worried about that. Bigger applause is on ShipIt where people try to deliver in only few days something that was requested 15 years ago around 2003 and what they really want, not what you think they would want. And even you work on something there is always a note (available only for XYZ platform, TBD for other) or even worse..

Let me give you one example (of many) how things are done in a REALLY wrong way -

The story of "Make field required only for one state transition" feature

For many years (I would say from the beginning when Mike and Scott developed Jira) it was not possible to do it OOTB.. only by plugin called Jira Suite Utilities (Atlassian Labs).. which had a field required validator... For this below issues where created to gather feedback and votes..

• Server -> https://jira.atlassian.com/browse/JRASERVER-5783
• Cloud -> https://jira.atlassian.com/browse/JRACLOUD-5783

We have 2015 and this is feature was still not developed. Dave Mayer in 2015 posted a comment on the Cloud version of the ticket (https://jira.atlassian.com/browse/JRACLOUD-5783?focusedCommentId=1421051&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1421051) where he mentioned:

"As many of you already know, the free JIRA Suite Utilities plugin can already provide this feature by way of a workflow validator. The plugin is supported by Beecom, an Atlassian partner. The plugin is available for both JIRA Server and Cloud customers."

Yes, it was preinstalled for Cloud and free for server users. Perfect! Then suddenly on Cloud we have an update from 20 July 2016 that..

"The Field Required Validator for workflow transitions has been incorporated into JIRA Cloud as a native feature. For JIRA Cloud customers, we recommend using this validator as the most direct way to resolve this use case.  For JIRA Server customers, the validator is still available by installing the JIRA Suite Utilities plugin, which is free and available on the Atlassian Marketplace."

Still OK, but wait.. when this would be for Server? Nobody cares until plugin started to cost money! Yay! And now we have updates on Server side also (from 8th December 2017) dony by Gosia Kowalska. Just those are completely different now..

"Thank you for commenting on this issue. Suggested functionality is available by installing the JIRA Suite Utilities plugin, which is available on the Atlassian Marketplace.  Suite Utilities for Jira used to be a free app/add-on until recently, and we realise that many Jira users considered its capabalities an integral part of Jira.  The decision to commercialize the app was made by the vendor. As soon as we learned about this change, we notified our users so you could plan accordingly.  We understand your frustration and we will share your feedback to the vendor. Ultimately though, it is the vendor's choice in terms of how they price their apps on the  Atlassian Marketplace.  As you know, Jira is a platform that anyone can build on, and the Atlassian Marketplace is a key part of what makes Jira so powerful.  As the Jira Server Team, we prioritize investments that impact the majority of our customers. We belive Suite Utilities for Jira deliveres great value to our customers and the plugin has proven to do it's job well. This is why we currently have no plans to implements JSU's finctionalities in the core product."

Wow! I was reading this many times and could not understand the strategy behind implementing new features on different platforms. On both sides first people recommend a plugin, then one side (Cloud) gets a native feature (even the plugin exist and have that implemented) and on the other platform a Won't Fix and not a single word that you would be implementing that for Server!. Is that the "TBD" what are you mentioning @Jason Wong? After more than a 15 years you get a Won't Fix even there is over 800 votes and a high need to get that feature. Cloud have it but Server cannot? Why? I am not surprised that comments after the announcement are not so good.

It is not good trend that the top voted features are only developed for Cloud and now also ONLY for next-gen project. Another example from JAC is for "Default values of system fields".. (https://jira.atlassian.com/browse/JRACLOUD-4812 and https://jira.atlassian.com/browse/JRASERVER-4812) .. Server have 1700 votes.. Cloud 1300 (and probably many of them duplicated when cloning) but the announcement is clearly pointing up that it would be soon available for Cloud and Next-gen project ONLY.  Server customers? Sorry you need to wait few additional years or maybe you would see a won't fix.

The point is that there is a difference between old and new users. New user do not care much about what Jira functionality is there in different platform. If they start using Cloud currently they can wait if we say them to wait.. I remember myself 10 year ago when I was watching and voting on most of the features on JAC. On the end there was always something more important on a roadmap than current need.. but now it is hard to believe that every new feature like Next-Gen idea (or any other) would be developed for Server at the same time. There are just too many differences already to catch up and changing the code based made a bigger gap.

Not sure what future would bring but I just only hope that every customer would not be "pushed" all the time towards one specific "best and supported" solution (like a perfect example HipChat then Stride finally Slack and now Cloud and Next-Gen projects). Please remember that behind every decision there are many people out there (admins, project managers, developers, testers, hr, legal, IT... ) that are using Atlassian apps each day and need to handle all those changes, transitions and very often that cost a lot of money and investment.

And on the very very end .. we are here.. community to help everyone understand the decisions (but sometimes it is really hard for us to understand them too). We need to handle very often a massive attack of questions after each announcement. Give people options that applications do not give and links to documentations or other resources that they cannot easily find. This is were feedback connects with frustration and confusion. This AMA is a small proof of that and thank you for being part of it too! :)

[Abel Lineberger]

1. How will the Portfolio product integrate with the new experience projects? 
2. How will new experience handle Initiatives?
3. How will the new experience handle issue relationships / dependencies?

[Jason Wong]

Hi @Abel Lineberger,

Right now, Portfolio isn't fully compatible with the new project experience, primarily because we have re-imagined issue hierarchy in next-gen and are working with a new data model.

The new experience will continue to be built out from a hierarchy perspective, so that we can support levels like initiatives in the not so distant future!

Other issue relationships are still handled via issue links in the new experience. 

[Jayme Rabenberg]

We like a lot of the features associated with next gen projects, but since we've been using JIRA for years, across many team, for development projects on multiple platforms we see migration to next gen projects a very difficult hurdle to overcome. Can you provide any guidance to a company that wants to move to next gen, wants to reduce some of the complexity and overhead of projects, and enable teams to independently build their workflows and have the agility they need to refine their process, and needs to find a path to migrate their current classic JIRA projects to next gen.

[Jason Wong]

Hi @Jayme Rabenberg,

Firstly thanks for the huge interest in moving to Next-gen. We have a lot of requests for more help moving from classic to next-gen. We are adding some highly requested features, such as sub-tasks, more field configuration, and refinements to epics (which you can track on our public roadmap) and in the future we will be doing something to make the move easier.

You might also want to consider the timing of the move to next-gen. Many teams are always very busy, with little time to focus on tooling but there comes a time when it's good to do a clean up and reorganize. Perhaps a good time is at the end of a project, or on completion of a retro where teams want to change the way they work. I'd then encourage them to try a next-gen project, independently configure it to what works best for them and only once they get buy-in to the new improved way of working they might then do a bulk move of issues and cutting over to next-gen (here's the bulk change documentation to move issues over from classic to next-gen).

If there are things they need that they can't find, please come back to us and let us know what those are.

[Werner Anders]

There are a number of features that are missing from the new jira issue view.  

1. No share button

2. No drag and drop of file attachments

3. Custom fields get lost on the right had side

I find myself switching over to the old view to address these missing features.  Is there a plan to bring back some of these features to the new view?

[Jason Wong]

Hi @Werner Anders,

The new Jira issue view is still being built to handle more and more complex functionality. 

1. The share button is on our roadmap and will come back sometime in Q3 FY19.
2. Drag and drop file attachments should be working - you should be able to do this by dropping it anywhere on the issue (which would attach it on the attachment panel). You can also open the editor on the description / comments (which would attach it within that content area), or when you have the option to select media (there is a little drag and drop window).
3. Which custom fields get lost on the right hand side? All custom fields should be visible or, depending on your config settings from the project settings → issue type, would be under the 'show more' option. If you can provide a bit more info, we should be able to address this.

[Barry Flower]

Can a link be provided to the NextGen Webinar on the 8th Nov so that I can share it with my colleagues please?

[Jason Wong]

Hi @Barry Flower,

Absolutely! You and your teammates can access the webinar on-demand here: https://www.atlassian.com/webinars/software/the-new-jira-begins-now

[Kelley Lawton]

What are the plans to support the Issues and Filters features?  It sounded in the webinar as if there is no plan to support Advanced JQL queries, nor necessarily the full Basic Search features.  Also, what about plans to support Bulk Edit of issues and CSV Imports?  Additionally, will there be Epic and Time-tracking reports?  These are all limiting factors which are keeping us from moving to the Next-gen project approach.  However, I seem to be able to access some of those features from the main Jira Issues and Filters link (outside of the individual project), but the results are inconsistent (for instance, it looked like I could bulk edit custom fields that are not even in the next-gen project even when I was only selecting tickets from a next-gen project.)

[Jason Wong]

Hi @Kelley Lawton,

For next-gen projects, we will be introducing ways to get to customized views.

We will start with a more user friendly interface - similar to say basic mode in issues search (which builds the JQL for you in the background).

Raw JQL (direct text input) is very powerful, but not everyone knows how to write an expression and limits the ways we can simplify things. 

For instance, you'll notice that in classic projects, you cannot drag and drop cards between the (swimlane) groups. This is due to having JQL defined swimlanes. JQL can be written in so many ways that it makes it hard to understand how to move a card between a swimlane. In next-gen you can drag and drop between your swimlane groups. We're aiming to retain this even when we introduce the ability to make customizations to your swimlanes.

Another example is, if you have a JQL defined classic board, it can also be hard to understand how to create a card that matches complex filters. When there are complex filters, often newly created issue sometimes will not be visible on the board, until you go and edit the issue's data to get it to match the board's filter. You'll notice that this no-longer happens with next-gen projects. Try selecting a few filters, 

These are just some examples of why we're not diving straight into JQL just yet with next-gen configuration. It is likely that over time we will allow a JQL override for even more advanced filtering that cannot be achieved with a simple but more powerful filter builder.

[Kelley Lawton]

@Jason Wong   Thanks for the reply!  What about Bulk Edit of issues and CSV Imports?  Saving filters?  (even just Basic filters)?  Will those be supported in Next-Gen?

[Jason Wong]

Hi @Kelley Lawton,

Yes we'll need to make sure those work and yes there will be a way to save filters - that's what I was mentioning above how we'll make that more user friendly through a basic filter kind of interface

We will start with a more user friendly interface - similar to say basic mode in issues search (which builds the JQL for you in the background).

[Alexis Jaillet]

Hi @Jason Wong

Next-gen JIRA projects are looking good !

Two main questions from my side : 

• How to manage releases with next-gen projects ?
• How to handle cross-projects releases with next-gen or current projects ? (without Portfolio)
  • Cross-functional project A + B + C = 1 fix.version / client / release.

Thanks in advance !

[Jason Wong]

Hi @Alexis Jaillet, 

We will be adding in a way for you to get to completed work and manage that by introducing something like Releases in classic projects. You'll find that when we do that, it will not only have a way for you to look at Releases by versions, but by using integrations with CI/CD and feature flagging tools. you'll be also able to get a view of what you've released to customers when you are continuously deploying code to production or managing feature availability with flags.

Cross project will come to next-gen later on once we've built more features to cater for single project use cases. 

[Oran_Dennison]

I love the vision of releases + deployments + feature flagging in a single unified experience.  This is what I get most excited about seeing in next-gen projects.

Hopefully you include support for Bamboo builds and deployments since Bitbucket Pipelines aren't available for Windows-based projects.

[Will McCall]

A few questions and requests around epics. Reporting, visualizing and templates. The addition of the road map feature is amazing!

1. In the Roadmap view i'd like to see issues completed/total issues in epic. 

2. I'd like to create a report to see all open epics, # of issues complete per epic, start/due date. This might be possible via the share Roadmap feature?

3. Any plans for epic templates? We have a set of repeatable tasks per epic. Currently using issue importer for classic and need a more efficient way to do this. I'd also like to pass the control to the users rather than admins which aligns with your Next Gen strategy. 

https://jira.atlassian.com/browse/JSWSERVER-7721

[Rico Neitzel]

I'd like to add: are there any plans an epic's status can be automatically switched if the underlying issues reach specific states?

[Will McCall]

I missed this one in my initial comment. My colleagues request this all the time. 

[Jason Wong]

Hi @Will McCall,

1. Thanks for the feedback! We are so glad to hear you're enjoying using the roadmap. Reporting, and how we better surface the sort of information you've mentioned, is something we are exploring at the moment. 
2. This kind of report is not available at the moment, but we can definitely take your suggestion on board. 
3. The new way we have implemented hierarchy with Epics would allow for this. For example with the new epics you can easily rename them - something you couldn't do in classic. We'll take your suggestion on board for when we look into next-gen project templates. 
4. @Rico Neitzel, I do think it would be likely that we'll help with completing epics when the underlying issues are complete, similiar to how we do that at the issue level when it's sub-tasks are complete.

[Jack Brickey]

I really haven't spent much time w/ Roadmap TBH but wanted to provide this feedback.

When I first looked at Roadmap I thought "Gantt chart". As such, I expected to be able to show/hide the children under the epic. This obviously isn't the case so i'm unsure how to really leverage the roadmap as yet. 

Another oddity is that I can drag the endpoints of the epic and it will change my start and end dates. However, if I have children (always i think) under the epic then the dates can suddenly 'violate' the bounding epic start/end dates. 

[Jason Wong]

Hi @Jack Brickey,

For our first version of the roadmaps feature, we wanted to start very simple. However adding the ability to view child issues is something we're currently exploring. 

With regards to the dates set on child issues, do you currently set due dates on your stories/tasks?

Currently we treat the dates set on epics versus any story-level dates set implicit (eg., assigned to a sprint with a date range) or explicit (due date is set) entirely separately. 

What would be your expectation on how this would work for your use case?

[Jack Brickey]

thanks for the response @Jason Wong. For dates on roadmap given this is an entirely new concept in Jira I don't have any historical data. That is, in the classic projects I only use dates on stories/tasks/sub-tasks. Epics are simply containers for my work. An epic certainly spans multiple sprints and also releases. I don't worry w/ the end-date of an epic as it isn't really important.

However, in the new Roadmap epics take on a slightly more important role where dates become important. That is, for me, dates in traditional roadmaps are important. So, when you display an Epic in gantt fashion, my assumption is that the tasks contained w/in the epic must remain in the boundaries of the epic or more accurately the Epic timeline needs derived from the children, i.e.  the earliest start and latest end date.

I hope this makes sense, if not feel free to reach out to me (you have my email) and we can discuss further.

[Michael Fenton]

Hi Jason,

The cleaner experience is appreciated, thanks.

Is it possible, or will it be possible to add Components to a next-gen project?

The component field is very important for us when it comes to generating invoices and reporting over JIRA, but we cannot seem to populate it in next-gen projects.

Thanks, Michael

[Johan]

Yeah, a broader subset of pre-defined fields could be nice, labels and components included.

But for now, I would advise to create a custom field on your ticket.
Project Settings --> Issue Types --> Select your issue type and add a new field.

[Michael Fenton]

A new field will not work with our reports.  We have thousands of issues under classic projects with the Component field populated, so it needs to be the same field.

[Michael Fenton]

Hi @Jason Wong,  Is there any plan for bringing Components into the next-gen projects?

[Navaneetha Krishnan D]

Integration between SharePoint 2010 and Jira.
Once a status field has been set to a certain value in sharepoint, the content of the sharepoint form need to be send to Jira.

Additionally, once the jira issue has been resolved, or changed to status ‘Done’, the sharepoint status field in the form must be updated.is it possible? kindly suggest a solution. thanks

[David Snoddy]

very good idea :-)

[Paweł Albecki]

When do you plan to add trello-like to-do lists in Jira issues?

[Jason Wong]

Hi Pawel Albecki,

Yes, we will be adding in what are called actions, which will work in a similar way to Trello. There will also be another type we add called decisions - just to give you more granularity on what tasks and decisions need to be carried out within an issue.

[Deleted user]

Why did you take away important and very convenient keyboard shortcuts like 'o' and 'e' for opening and editing issues? This has reduced the efficiency of viewing and editing issues. Instead, you should have encouraged users to use more shortcuts.

[Jason Wong]

Thanks for the feedback @[deleted],

Keyboard shortcuts are on our list and we will be putting them into next-gen projects to help you power through your work.

[Terri Bartos]

Roadmaps vs Portfolio?  Does Portfolio come across to, or link with, this new platform or is Roadmaps a replacement for Portfolio?

[Jason Wong]

Hi @Terri Bartos,

Roadmaps provides a very different sort of solution for teams - it has much less depth in terms of functionality than Portfolio. If you have very simple roadmapping needs, then perhaps it could be a replacement for you. However if you still need something that is more in-depth, then we recommend Portfolio. 

[Clair Lawson]

A few questions from the webinar please:

Can we migrate open issues to a new next gen project - is there a link to the instructions for this please?

How easy is it to create sub tasks?

Can tests be created in next gen, as tasks directly related to an issue?

Are version numbers able to be assigned to next gen, or is each project a version?

[Nilesh Patel]

I would be interested in the answer to these questions as well. 

Clair, for subtasks I think this is an upcoming feature (top on the list) that we do not know when it will be released.

[Clair Lawson]

Hi - yes after more research, sub tasks are not available yet. I am trying to work out if this is a show stopper for me or not at the moment. I think I will use next-gen for a few smaller projects initially and see how it goes.

[Alvin Cruz]

Would love to be kept informed of this also. We have Zephyr in the classic version but cannot get it up and running on Next-Gen projects.

[Dave]

Have you noticed a severe performance degradation in Internet Explorer? Many users in our company are required to use IE11 (central software management etc.) and experience page loads taking approximately 3 times longer than in Chrome.

[Jason Wong]

Hi @Dave - I feel your pain.

You're right, load times in IE11 aren't as fast as Chrome. It's something we are aware of, but unfortunately, there isn't a whole lot we can do to fix at this time. Internet Explorer is an old browser, and simply is slower than Chrome.  

[Dave]

That's a pretty weak response, especially as the "old" UI loads in comparable time in both browsers.

As a long-time developer of web applications I know there are some particular tasks at which IE is significantly less efficient than Chrome. It's possible to create your application in such a way that these limitations are avoided (or their impact reduced). As many companies and institutions are bound to the MS tools and simply won't move from IE it must surely be worth your while to keep these users happy.

Perhaps start with reading this:
https://stackoverflow.com/questions/4538443/what-are-the-likely-main-reasons-my-website-is-very-slow-on-ie

[Mark Roberts]

Hi @David Swain, I'm with @Jason Wong on this one. we can't hold on to IE11 forever.

Your reference article regarding slowdown is from 8 years - 2010 , the year the first  ipad was announced.

[Dave]

Of course I understand that technology moves on and we can't support old software forever. I'm not advocating it work on an Atari, or in IE8, just the latest version of the IE series of browsers. This version is still supported by its vendor so should be viewed as current.

Looking at some stats on http://gs.statcounter.com/browser-market-share (which of course is context-free and potentially skewed etc. etc.)
IE has a higher market share than Edge. I know ~2% of the market is tiny compared to Chrome's mighty 61% but I wouldn't have thought Atlassian would want to irritate 1 user in 50. Those 2% are often using IE because they are in businesses who insist on MS products for the perceived superior central management and security and who lag behind the curve a bit so haven't adopted Edge. As such the target audience of a product like Jira (businesses) contains a higher number of users who can't move away from IE than those stats would suggest.

Quite aside from the "don't annoy your customers" argument I take issue with the notion that a web application needs a really efficient JS engine to function. The server version (with the old skin) works perfectly in IE and proves it's possible. Just because computers are more powerful and most browsers are better at dealing with inefficient code doesn't mean it's good or right to carelessly bloat your application and pay no attention to performance.

In case you think I'm a random complainer alone on the web perhaps this article will persuade http://idlewords.com/talks/website_obesity.htm . Also consider that the age of my reference article just serves to show that this is not a new problem so surely experienced developers should be used to mitigating it.

[Dave]

https://jira.atlassian.com/browse/JRACLOUD-69055 appears to be acknowledgement of this. If you are stuck on IE and want to use Jira's new experience (which I can only imagine will become the standard experience within a year) I suggest you go vote on it.

[Jezz_Dalgarno]

Hi Jason, will you be implementing an option for boards to auto-size the width of columns? The removal of this feature makes my boards overly compressed (I have 4 cols and a decent resolution) and harder to read.

[Jason Wong]

Hi @Jezz_Dalgarno,

We don't currently have plans to build this and but we're definitely not opposed to the idea forever.

For some background on this, fixed-width columns was the trade off we made when building inline column management with horizontally scrolling boards. You'll notice a mini map on the bottom right to show you where you are in the scroll range to help give perspective on where you are when zoomed out.

[David Stokes]

Hi Jason

I've just put a post up in the Atlassian community page, but it looks like it would be better to put it here..

I'm getting pretty frustrated over the transition to the new JIRA UI.  Don't get me wrong, the old UI is really hard to use, particularly for new users - it's well overdue for an overhaul.

But what I'm struggling with is the way this transition has been happening.  I'm getting the distinct feeling that the approach being used by Atlassian is removing all functionality and then see what users complain about it not being there.

For someone like me, I know how to find my way back to the old UI, but I'm really concerned about the impact on new or less experienced users.

Take the example of links between JIRA pages and Confluence - this is meant to be leveraging the excellent integration between the tools and why it's better to go down that track rather than integrating tools from different vendors.

In the new JIRA UI, it does not allow you to create or view existing links to Confluence pages.  OMG!

I have recommended and implemented the Atlassian tools in well over 20 companies, but I'm starting to reconsider whether it's the right thing to do with issues like this.

I'd really like to have some sort of reassurance that these issues are going to be addressed well and quickly.

Regards
David

[David Stokes]

BTW - I did report this as a bug a month ago, this is the response I got from Atlassian:

"While we'd love to say this will be fixed soon, we're unable to give an estimate for fix just yet. We will be following up with our bug fix team on your behalf for this issue, as they will need to continue to assess the impact and prioritize the issue against our current backlog. If you want to be updated on the progress, please feel free to add yourself as a watcher to the bug report.

I am attaching our bug fix policy as an FYI : Atlassian Bug Fixing Policy"

[Jason Wong]

Hi @David Stokes,

Thanks for the feedback and the example of the support response. I'll do my best to address your feedback and sort out the support response to this.

In order to simplify we haven't just removed or hidden functionality. We had learnt quite early on that changes to UI alone will not be enough to simplify usability, yet retain the power in Jira's configuration capabilities.

The new Jira is built from the ground up and so we've been coming from it the other way where we add functionality layer by layer to a new platform.

We've added next-gen as a new type of project in addition to classic so that you are in control of when you want to move.

What doing is involving everyone early on which is why it might look like we have oversimplified. We are on a mission to build a lot more functionality into next-gen, with the flexibility to cover a super wide range of team needs from simple to advanced - we'll introduce custom views / filters, templating and cross project views, to name a few of the things we'll be adding to next-gen. 

Also, the Jira to Confluence links will be there in the issue details like before, we've just yet to add that back in. You'll also see that we recently added the new Pages feature that allows you to see Confluence pages in your Jira project (project level integration).

There's a ton of features we're overhauling to make these next-gen projects our best yet and will work hard to implement what you need so that you'll want to make the move.

[David Stokes]

Thanks @Jason Wong for your response.  Making this significant change is tough.  But what must remain the highest priority is the impact on the user experience in this transition.

[yubin99]

Hi, Jason. I have a difficult problem about gadget: after we installed jira 7.12, we already get _msg_ error in Activity gadget. I have tried all solution in Atlassian KB articles, it doesn't help at all. We are using jira 7.12 on Linux with reverse proxy with Windows 2012 IIS in the front. Please help!!!

Here is Atlassian KB article: https://confluence.atlassian.com/jirakb/health-check-jira-base-url-859447384.html

Thank you.

[Mirek]

I think this AMA is related to Jira Cloud not Server but maybe you can create a new Question on community or directly a ticket to Atlassian and someone would be able to help you with your problem.

[Rico Neitzel]

Also I'm pretty sure "anything" doesn't mean: "technical issues with your instance" … that's what the support tickets are made for ;-)

EDIT: To be clear: If you really need help, create a support ticket. then you'll get fast response fromm a highly qualified support agent! 

[Hugo Rocha]

That's kinda of rude, no need for that, Rico 🤔

[Rico Neitzel]

I'm sorry :-( It wasn't meant to be rude but more like a winking info, that atlassian has support for those issues, where you don't have to wait till someone MIGHT answer here in that AMA … :-(

[Jason Wong]

Hi @yubin99,

The others who have responded before me are correct in that this is a very specific question about Jira Server.

While I'd love to help, our support team is going to be much better equipped to help you. I suggest you log a support ticket here: https://support.atlassian.com/

[Oskar Collin]

I like to use some kind of "Ready for development" column as the first column in our kanban boards. But if I turn on the backlog feature and add something to the backlog in a next-gen project, everything that is in the backlog "board" has the status ready for development (which is the first column in the board but separated from the backlog feature).

If you have the backlog feature on, shouldn't the status for the stories in the backlog have the status "Backlog" and not the status of the first column in the board?

[Jason Wong]

Hi @Oskar Collin,

In next-gen projects, all the statuses that are available are represented on the board. For example, the way to create a new status is to add a new column to the board. Since there are no statuses that are not present on the board, there is no way to have an additional status right now that is only visible on the backlog.

The other thing that has changed is that we have aligned the way the backlog works so that it’s consistent, whether you are not using a backlog at all, use only a backlog, or use a backlog with sprints.

In classic projects these all worked in slightly different ways, but in next-gen projects sprints and backlog can be added to (or removed from) the project as independent features. To make this a seamless experience, the backlog now behaves a bit more like the old scrum backlog used to work, where issues could be on the backlog in any workflow status.

For your use case, I would recommend that you create a column called something to describe the status you define that comes before something is "Ready for development" eg. Triage and make "Ready for development" your second column on the board.

[zhangwei]

I want  to know Jira's future plans, new features, new versions, where can I find them?

[Nilesh Patel]

@zhangwei this is the information that we all have. 

https://www.atlassian.com/roadmap/jira-software

[Jason Wong]

Hi @zhangwei,

Yep - the link provided by @Nilesh Patel is the right one. Thank you!

[Takeshi Ohishi]

The new next-gen project looks good and promising (especially, the built-in roadmap view is great.)

I'd like to assign an Epic to tickets more easily (e.g. with a quick action by ".")

[Jason Wong]

Thanks for the feedback @Takeshi Ohishi, we're really glad to hear it. 

We're working on how we can make it easier to assign epics to issues, similar to what you mentioned - stay tuned.

[Steve Larsen]

We have a template project set up with workflows, screens, custom fields, etc. that is used as the basis for new projects. When creating a new NGen project I selected the option "Share settings with an existing project" and the project created successfully.

However there are no boards created initially (the template has 2 boards). When I go to create a board in the NGen project, I am presented with 2 new options:  Project (select 1 or more projects to include) and Location (select a Software project or your own profile as the place where this board will live).

Can you explain these 2 options and the ramifications of choosing an existing or new project/location?  If this is documented please provide a link and I'll go read up on it!

[Jason Wong]

Hi @Steve Larsen,

Thanks for your feedback. When you select the option to create a project using the "share settings with existing projects" it creates a classic project. Currently we don't have a way to create a new next-gen project based off an existing project. However we plan to introduce templates which will allow you to share project configuration between projects.

[Jason Kolpack]

Is there a convenient way to mark issues as ready for the next state for a traditional pull Kanban flow?

[Rico Neitzel]

Can't you just use another status for that?

[Jason Wong]

Hi @Jason Kolpack,

Here are a few ideas on how you could mark issues as ready for the next state:

• Move the issue to the next state, but leave it unassigned (so it is ready for someone to pick up);
  • If you view your board by assignee, this would clearly distinguish between assigned and unassigned issues
• Assign the issue to your next teammate but leave in the current state, so they know to drag it over when they are ready;
• Use labels to make visible on the issue when work is 'ready for next' or such.
• @Rico Neitzel's suggestion might also do the trick.

I hope this helps!

[Jason Kolpack]

Another status is what we are currently doing, but in order to keep the work in progress limits accurate we have to combine statuses in one column.  You then lose the ability to drag issues between states which is a nuisance.

I can think of a number of problems with trying to manage it by using the assignee.  We've found workarounds that mostly work, but in a prior role we used Agile Central which made the process much more natural.

I would think doing something like adding a ready flag to the issues would be the best option.  I tried doing this with a custom field but again, was not optimal as there didn't seems to be a great way to add a boolean field.  We ended up having to add a Yes/No dropdown which ended up being a little confusing.