Future of Data Center Ask Me Anything (AMA)

[#1]

Hello Atlassian Community,

My name is Gosia Kowalska, and I am Head of Product, Data Center. I am joined by Niall O'Riordan, Head of Engineering, Data Center, and Partha Kamal, Head of Product Team Enterprise.

On Wednesday, May 25th (PST) we will be hosting an all-day AMA to answer your questions about the future of Atlassian Data Center. We recently shared our focus and vision for the future of Data Center in a community post here and our leadership teams would love to hear any remaining questions from you.

Here's how it works:

Add your questions below any time before or during the AMA. Be sure to take a look at other community members’ questions and up-vote those that you find interesting.

Starting on the morning of May 25th PST you can expect to see answers from us and our teams start rolling in. Watch the page and be ready to add follow-up questions and discuss further with other Community members. We'll wrap the event at the end of the day, but will be sure to answer any questions we didn't get to.

Cheers,

Gosia, Partha, and Niall

[Dan C]

Is the ProForma form builder going to be coming to Data Center?

[Dan C]

When will Jira DC get a dark mode - it's been in AUI for quite a while now.

(This is the 2nd highest voted issue for Jira DC, but still "Gathering Interest")

[Dan C]

Is there any possibility in the future of using Forge, or a similar tool for app development on DC products?

[Dan C]

When is the "Atlassian Teams" functionality coming to DC?

[Dan C]

When will the crowd subsystem be updated to allow renaming of groups, and using an ID to identify them as unique objects instead of name?

(Number 1 voted item for Jira DC)

[Dan C]

Is there any thought of an official Insight DB "clean/fix/integrity check" feature?

Our Insight data is a real mess, and has many buggy "ghost" records, duplicates, random errors when trying to delete items, and other strangeness that made it into our data through years of bugs that existed previous to Atlassian purchasing it.

Now, it feels like the only true way to clean up our insight "db" is to wipe and start fresh, but we can't do that due to the heavy reliance on our data.

[Carmen Nadeau]

Will Pro-forma allowed traduction ? We are a bilingual cie and this iss needed.

Don't tell me to create a condition associated to the language because once you do this, you can't use any other condition in this segment. Might as well use "normal" customfields

[Matt]

Confluence - Content Lifecycle Management. Any improvements slated in this space?

Currently, users are required to manually mark content as archived using the built-in features. We also have "Better Content Archiving", however, our users were up-in-arms when we tried to enable it and automate content archiving.  "In-house" problem, I know, but we'd still like something in the middle. Also, the 3rd party add-on does not work on Confluence Blogs.

Here's solution mode; Something like a "soft archive"? I know that "soft <enter action here>" is all the rage @ Atlassian these days due to that recent cloud kerfuffle. Or perhaps a visual indicator based on usage/consumption that the content is less relevant/consumed? Allowing the content author to be nudged and acknowledge and move on or rather choose to archive. Possibly link that into their profile for "My content status" similar to the Drafts section.

[Matt]

To follow through, Confluence Analytics, we'd like to see improvements in this functionality as well.
PII is an issue and the fact that it's all or nothing and data collection is reset when toggling this attribute is a pain. It'd be more beneficial to obfuscate the data upon display rather than during collection.

[Matthew Martin]

Relating to Confluence DC

In our org, deleting data at all is a high-risk activity because of compliance with retention laws. In its current form, Confluence offers almost no solutions or functions to help us tackle this problem. 

Now, disabling deletions sounds like a nightmare of a time and I don't think it's realistic but how could this problem be tackled alternately? Through visibility.

If pages based on age simply dropped out of sight and were indefinitely retained, the problem largely is solved. In walks the same base concept you've already implemented in JIRA DC around archival.

• A page in Confluence has an index related state: active or archived
• Pages marked as archived are dropped from the index, UI, and viewed through context-specific space-related screens for archived data
• You make my year by additionally introducing some automation around this and tying automated archival of pages to timeframes (eg, not edited for 24m)

Do you have any plans relating to the above?

[Matthew Martin]

Relating to Confluence DC

We have a considerable issue with page complexity.

When it comes to how a user structures content on a page, we find more often than not users flow to the path of least resistance. What this means is that instead of building content through multiple pages that are linked, a user builds a single, monolithic page filled with multiple data types (some pages having hundreds of macros).

Our instance is performant and Confluence can generally handle these pages with the worst outcome being, a slow loading time, however, we note a number of these pages become uneditable at a certain point meaning the user gets stuck and has to either roll back the page to get access to it or start again. This issue seems to be a user's browser getting overwhelmed with the amount of data Confluence is returning to load.

The user's response when we encourage them to simply structure their content differently? "Confluence should be fast enough to do whatever I want it to do!", and that's honestly the problem. Confluence allows users to create inefficient, and problematic outcomes on pages and provides no insight or guiderails to help or direct them.

This is a hard problem to solve and I don't think it should be solved by some rigid, codified walls in the app however, what I would love to see is the implementation of some tips or warnings to users about page complexity.

For example, if I have a user whose building a page and they reach a certain threshold for a number of macros, it might be helpful to display a message that says something like, "Your page has a large number of macros. This can lead to page slow load times. Consider splitting this page into multiple pages" or, if a user has a page that quite simply is incredibly long, the user might get a warning like, "Your page is getting quite big. It can be hard for users to find what they are looking for. Consider splitting your content into multiple pages".

Anything that can proactively help a user make better choices about constructing their content is a win to me. Keen to hear your thoughts on this.

[Carmen Nadeau]

JSM

The ability to move/use the configuration of a request type to another project. For the moment you have to recreate everything 

Make request type groups global so you can display you request type logically in the Portal and not be bound by which project team will implement the request. A ITSM Catalog can't be bound by implementation teams, you have to have a logical grouping of request type

[Taranjeet Singh]

Most of my questions have already been covered by other members here!

Looking forward to seeing the responses from all of the leadership team on May 25th.

[Dan C]

I agree 100% wth @Carmen Nadeau above - the service portal and all the request types within service management projects need to be way more flexible to provide a good user experience to the customer.

The design/layout of the portal should never be project based, the customer view should be a completely separate layer that has no ties to internal project organization etc.

This is one of the problems we're dealing with in terms of trying to create an organization wide service catalog. Being tied by the internal project and request type is part of is driving us toward the idea of potentially writing a completely separate layer for the actual front-end that customers see, so we can separate customer view from internal project organization - which is a shame.

Overall, the service portal appears to be one of the most under-developed, and least customizable parts of Jira, and the responses are usually "that's not how jira works" (the problem being that Jira's internal architecture was designed for software development with smaller scale groupings of people) - is this likely to change in the near future?

[Lara Lopez]

I want to expand on what Carmen said, not just use and move request type between projects, just simply being able to copy them.

When all my request types in a portal require ten fields, configuring that manually again and again becomes boring very soon if I want to configure a lot of request types with similar set up.

[Lara Lopez]

I wanted to ask as a separate question when are we going to improve Context management for customfields?
For datacenter context for custom fields becomes vital to manage your instance and guarantee performance.

The new menu when you create a custom field to choose the issuetype and project is a step in the right direction. But if you want to edit the context I can't believe we are in 2000 still.
The issuetypes are not alphabetically ordered, so if you have a large instance you will lose minutes scrolling really slowly in a tiny box searching for your issuetypes.

Or if your customfield already had a context for one project and you want to add another, or another issuetype you have to very carefully press shift while clicking as not to lose the other selection. Is the hell of administration.

[Carmen Nadeau]

JSM

Within a request type, if the field label that is displayed in the Portal is changed, you have to modifiy this field to see wich "real" field was used in the request type, which is time consuming

[Troy Chaplin]

I've been compiling a list of questions over the last few days. Going to post them all in one comment and will add any new questions here as I think of them.

1. When can we expect integration between Insights and Proforma so we can leverage insight object or relation custom fields in request type forms?
2. When will we get a native dark mode feature, current plugin offerings leave much to be desired
3. When are the DC docs going to be improved and get better SEO treatment? 9 out of 10 docs that I find are for cloud and the DC equivalent sometimes can’t even be found
4. Why am I forced to have the cloud migration plugin in my DC instance? It’s caused upgrade issues in the past and even when I delete it somehow it gets put back in. Please don’t force that on us.
5. Will work management every be fully integrated into DC. If not, why is this being kept as a cloud only feature?
6. Request types: cloud offers a neat drop down option to easily switch forms on the fly, this appears to be directly tied to groups used in request types. Is that functionality going to be added to DC in the near future?
7. Are there any plans to upgrade the overall look and feel? While I prefer navigating around DC I find it looks dated, whereas the design of cloud truly feels like a modern web app
8. Theming the portal. Why aren’t there any good ways or good resources on theming the portal. I’ve checked out some plugins, and while they are good, they still don’t let me have the control I want. In cases where Jira Admins have access to web designers and developers it would be nice to be able to work with them to truly brand our portals to follow organization approved brand guides.
9. Can we expect improvements to issues in the portal to allow customer to see issues linked to their primary issues, or subtasks? I often have the need for this, and have used the Message Field plugin to inject vanilla JS to do this in a basic way, but an officially supported method of configuring what is and is not visible in portal issues would be a welcome feature
10. Improved authentication for importing into insights, basic is not always acceptable, I’d like to see OAuth2.0 used here. I currently have to build out a multi-stepped configuration to consume a csv file on a nightly basis when I just want to consume it directly from the API feed, but the lack of a more modern and secure authentication prevent the easiest path
11. When adding custom fields will we ever have the ability to do more than one context per project but tied to individual issues types? Would be a welcome feature to have a single field that could be used differently in several issues type in the same project
12. What is the internal process for reviewing and approving feature requests? I have never seen a piece of software that gathers interest for half a decade or more and sits there in limbo, especially where there is a significant number of votes and comments begging for that feature. Some of which are already in cloud.
13. Make accessing insight attributes in smart values as easy and well documented as it is in cloud. It has been noted as not supported in DC and the issue relating to this feature request has been gathering interest for over a year.

[John Dunkelberg]

#3 on @Troy Chaplin 's list is a definite annoyance.  To phrase it as an AMA perhaps "Does Atlassian consider it a goal to have DC and Cloud present equal documentation?"

It certainly also reflects badly on Confluence that we consistently get "This exact page does not exist in our Server 8.13 documentation. Would you like to look for an alternative page?" and when you say Yes, then it immediately comes back with "No search results found."  It reinforces feedback from our users about poor search capabilities in Confluence.

[John Dunkelberg]

Does Atlassian plan to provide an full API for Advanced Roadmaps?  There was a 2018 announcement, but that was before the Live Plans were deprecated.

[Dan C]

#11 in @Troy Chaplin 's list would make the world a better place.

[Rachel Purpel]

Is moving to object storage (out of file storage) on the road map?

[Rachel Purpel]

With regard to #3 on @Troy Chaplin 's list, it should be noted that documentation search in DC doesn't work *at all.*

Example: https://confluence.atlassian.com/search/?productName=Jira%20Software&productVersion=8.20&queryString=sprint

[Matthew Martin]

Relating to JIRA DC.

One of our biggest ongoing issues relates to the ever-growing configuration data scope for projects (issue types, screens, custom fields, workflows). A pretty common issue for any instance that's survived for years and has scaled. It's so hard to fight off the performance hits and the tool is so ineffective at helping.

With the introduction of the archival feature, we've now been able to remove projects from visibility which is fantastic but the reality is that archival does nothing to reduce configuration scope. An archived project from a configuration perspective is equivalent to an active project in how it requires the configuration underpinning it to be retained.

In the past, the answer we've received in regards to this from Atlassian of "export the archived projects, delete the projects, and then delete the configuration" does not cut the mustard at scale. We need real thought to be put into how configuration data can be deprecated or at least ringfenced when it's no longer associated with active projects. We don't have the time or capacity to manage the process of detaching configuration data from projects and deleting it. We need something in the middle.

[John Dunkelberg]

Great point @Matthew Martin - to expand that to adjacent areas, my question would be what Atlassian envisions as the ability to not merely scale their solutions in terms of sustaining performance with an increase of users or issue count, but in terms of maintenance and extensibility.  There is a patchwork of third party solutions for cleaning up unused boards, filters, dashboards, etc. but even these appear to suffer from a lack of design for maintainable scale within the architecture of the products themselves.  The infamous "View on Board" is a red flag planted on the tip of that iceberg.