Transcript: The Atlassian Ecosystem Podcast Ep. 142: What's the Frequency, Confluence?

Ryan Spilken:

Hello everyone, and welcome to the Atlassian Ecosystem podcast. This is episode 142: What's the Frequency, Confluence? Great question. Well, I'm your host, Ryan Spilken, and joining me today is the Peter Buck to my Mike Stipe; Brenda Burrell. Brenda, how's it going?

Brenda Burrell:

Much better now that comparison has been made.

Ryan Spilken:

We could talk about peak-era REM all day, but that's not what we're here to do today. We are here to talk about-

Brenda Burrell:

I could talk about that all day as well

Ryan Spilken:

Yeah, right. I know. We're here to update you on all the things that are going on in the Atlassian ecosystem beginning with the Atlassian Cloud, where we start with an update to Jira Service Management, where now, Atlassian has improved naming for imported object types for Insight. When you import a CSV or JSON data into Insight for Jira Service Management, you'll be able to automatically create a new object type using that data. The name of the new object type will now be the file name of your source data. Does that work for your asset management needs? We sure hope so.

Brenda Burrell:

AHA, in Jira work management, you can now select and drag your cursor across multiple dates in your calendar to fill in the start and do dates when creating an issue. I love this. This is so visual. This just makes my brain happy. The issue detail view will open and your issue start date and due date will already be filled in. So you only need to fill out the rest of the issue details. Once you have entered those details, select create and the issue will be added to your project in visible, on the calendar, and in other views, huzzah.

Ryan Spilken:

Oh, that is so nice. I'm a big fan of the calendar Jira integration. So the better they make that, the better for everyone.

Brenda Burrell:

All around.

Ryan Spilken:

And another quality of life update in the Atlassian Cloud products comes in Confluence where... And this is a big one, you can now add a status to your page. Now, we don't know exactly what this looks like yet because there's no sick gift to show us, but Atlassian states that by giving your content a status, you can help set expectations for viewers and collaborators when they come to a page. There are a few basic statuses that are available by default, but creators and editors can also add custom statuses that work for your team or your project. These are being left to the admin of the space to control what statuses are available per space. And the space admin can turn off statuses completely if they so choose.

Ryan Spilken:

I'm pumped about this feature. I am so pumped about this because you can, of course, start a Confluence page, use a template, change the status that's built into that template. But as anyone who's used Confluence for any length of time knows, page templates start changing from space to space over time, et cetera. And that Atlassian is making a page status part of the overall Confluence experience. That is an awesome move in my book.

Brenda Burrell:

This is more than a quality of life update as someone who earns their bread and butter in knowledge management. This is a massive update that has been just sort of buried a little, oh my gosh, status is on Confluence pages. This is something we've been begging for a long time. And it's really going to change the way I think people interact with Confluence because sure, you could remember to put a lozenge on your page that says this is draft, but you may or may not remember. Everybody does it a little bit differently having a consistent experience across the entire Confluence instance, this makes my knowledge management heart so happy. I cannot even begin to express what a huge update this is. So is it perfect? Probably not. Is it a step in the right direction? Absolutely.

Ryan Spilken:

Oh, hell yeah.

Brenda Burrell:

Hell yeah.

Ryan Spilken:

I went through and looked at the roadmaps for cloud versus data center today when I was preparing the articles for this podcast. I got to say there's a lot of stuff that makes the end-users lives so much better coming to the cloud, and virtually none of this is planned for data center. And I hope that somebody out there in Atlassian world recognizes that is less than awesome for the hundreds of thousands of people who are still using data center to manage their team's projects. Bring some of that into the on-premise solution team. Please.

Brenda Burrell:

Here.

Ryan Spilken:

I'll drink to that.

Brenda Burrell:

Moving on from cloud news, an update to Atlassian personnel, Atlassian has announced that Rajeev Rajan will be joining in May as the company's new chief technology officer. Prior to this, Mr. Rajan was at Meta for nearly five years as Vice President and Head of Engineering. And we're just really looking forward to seeing what changes Rajeev Rajan might bring to Atlassian.

Ryan Spilken:

I'll say that once Adaptavist appointed a CTO, our first CTO John Mort, things definitely started taking a positive tack in the product delivery sphere. So it can only make things better.

Brenda Burrell:

And that is a wonderful opportunity for us to mention that John Mort will be joining us on our next episode. So to our viewers at home, tune in next week for an introduction to the man himself, CTO John Mort.

Ryan Spilken:

Yeah. We're going to welcome him to the Thunderdome with a...

Brenda Burrell:

He has no idea what he's in for. Does he?

Ryan Spilken:

Yeah, he really doesn't. But we look forward to speaking with John. He'll be able to bring in a lot of backend of the development knowledge and how that can affect you, our listeners, and using your Atlassian products. So the next episode, look for our CTO John Mort. And finally, Atlassian has issued a post-incident review on the infamous Team '22 outage, the April 22 outage. And this is a toothy update, to say the least.

Brenda Burrell:

That it is.

Ryan Spilken:

It begins with a letter from Scott and Mike and goes down into a highly detailed so much so that the description is multiple paragraphs before it finally gets down to the table of contents where they actually talk through everything. The beautiful thing about this is that it's public. It's well done. It's concise. It does take responsibility. It shows how the team is planning to make it not happen again. And if you were one of the people who are affected and you're concerned about Atlassian's stability going forward, I highly recommend you check this article out.

Brenda Burrell:

It really is a study. We screwed up and we take responsibility for this. The way it's written, it's very professional as a PIR should be. What it boils down to was a communication gap where a team requested a particular deletion and then a different team ran a deletion of some fields for it basically around Insight. And what ended up happening was instead of deleting certain bits of data deleted entire sites, and there were insufficient system warnings in place. The API that was used to run this deletion did not differentiate between here's a small thing and here's a big thing.

Brenda Burrell:

So they have summarized it as there was a miscommunication between two teams. And then there was an API that didn't ask for a confirmation that really should have been asked for. So if you were affected or if you weren't and you want to see just kind of the gold standard for what a good PIR looks like, we'll have this link in our show notes, highly recommend. It's beefy. You don't have to read the whole thing, but if you're interested in it, there's a lot of information there. And it's exactly the kind of response you would expect to see from a company that had a two-week-long outage.

Ryan Spilken:

There's one important bit of this PIR that I want to point out. And that is under how will we improve Atlassian's states. As we move forward from this incident, reevaluate our internal processes, we want to recognize that people don't cause incidents, rather systems allow for mistakes to be made. That's beautiful. They're not blame, there's no blame game going on, there is a look at the broader picture and a proper response. It's just great.

Brenda Burrell:

Now, this all started while we were at Team '22. I was getting ready to deliver a training course on incident management no less. And I actually ended up pulling up Atlassian's page as an example throughout the day, because I ran two courses on incident management. They started off strong. Hey, there's, there's an incident we know about that we're investigating and there were regular updates and then it just kind of dropped off. They are right to say that there's some improvements that can be made in how they handle those incident communications. At the beginning, I was like this is how it's done. Look, there's updates. There's regular updates. They're coming in, then suddenly it was just not there anymore.

Ryan Spilken:

They acknowledge that the complexity of this outage became so much that their comms team was overwhelmed.

Brenda Burrell:

Overwhelmed.

Ryan Spilken:

Yeah. It says that at its peak, this incident had hundreds of engineers and customer support employees working simultaneously to restore customers' sites. Our incident management program and teams were not designed to handle the depth, expansiveness, and duration of this type incident, but they are changing it. And they're outlining exactly how they're going to change it. Just fantastic stuff.

Brenda Burrell:

Will be interesting to see how some of those improvements actually go into play. But for now, this is what Atlassian needed to do. And I think they've done a good job with it. Well, that's really it for this episode. Thank you so much for listening. Please, as always, comment, like, and share wherever you comment, like, and share podcasts. If you'd like to reach us, comment on social, we're at @Adaptavist. We would love to hear from you. And for Ryan Spilken, I'm Brenda Burrell, and that's it for this week. I had a mental image of myself in full Viking costume raising a chalice of me going...