Happy Wednesday, Jira Guys and Gals. I hope you are excited about next week and have mapped out what sessions you want to see at Team '23, virtually or in person. I know my calendar is already filling up with meetings, sessions, and events, and I'm so excited to see everyone in Vegas!
However, that's next week; what are we talking about today? Well, Atlassian put on a webinar about a month ago about Data Center's Roadmap. Unfortunately, the webinar conflicted with another meeting I couldn't miss so I couldn't attend...which was a shame. But Atlassian's Roadmap for their products is public. So, given that, we'll take down what they are working on - product by product - and see what the rest of 2023 has in store for Atlassian's current on-premise offering!
I'm starting with this one as a JSW idea, but this is listed for all their products. The idea is simple: Within the Application, I should see the breakdown of HTTP requests. Why would I want this? Well, a sudden spike in requests retuning 500 is an excellent indication that there's a problem in Jira, and I might want to know if my users are experiencing it. Likewise, a sudden spike in 404 errors might indicate a wrong link somewhere, 401 might point to a problem with your Authentication infrastructures - the list goes on.
If you want this kind of insight today, you must scrape logs with another tool. This change would put it right in Jira. Of course, if you also get the 500 error, it won't be too helpful, but it would still be a nice analysis tool to have.
If you have ever self-hosted a Jira instance, you know one of your principal concerns is disk space and utilization. Running out of disk space can throw Jira into an outage, and a high disk utilization can cause performance issues.
Now being completely honest, Avatar files rarely feature in either of these. Instead, the main growth mode for disk usage is attachments, and for disk utilization is the Index. That said, every little bit helps, so offloading the Avatars to an AWS S3 bucket won't hurt your system performance. So is this something everyone with a self-hosted instance should celebrate? Not really. But it will be nice if you are already hosting your Jira instance in AWS.
This idea is about the Issue View and is meant to appease two competing schools of thought. Some believe empty fields should be hidden for the issue view screen (not the Edit or Create screen). If it's empty, that data is not important (by definition), and not having it show up reduces clutter and helps an instance look cleaner.
Conversely, you have those who think an empty field is information in and of itself and should be shown. This is the school of thought I find myself more closely aligned to, though I can see the other side's point.
This idea is to make this behavior a selectable option. And that could be great, depending on how Atlassian implements this. If it's something you can set per project (or, better yet, per issue type), that would be an amazing amount of flexibility to determine how a project looks and works. On the other hand, if it's a setting for the whole instance, I don't know if it would be near as useful. Setting it up for the former will be more work, but it would improve the proposed feature infinitely.
This feature is rather simple, and I'm surprised Jira Software doesn't do this already. The idea is that Jira will automagically(tm) set the Start and End dates for your sprints. This is perfect for teams with a consistent sprint - if you know that your sprints are always in two-week increments with very few exceptions, why would you not want Jira to recognize and fill your sprints out as such?
So, the mail queue. You may (or may not) be surprised how many of your user's workflows depend on getting an email from Jira. So when it breaks, that's a big deal. One failure mode I'm fairly familiar with in Jira goes as such: Your upstream email provider fails, and Jira cannot send out emails. So it holds onto the emails in the queue - which, within a few hours, can cause the queue to swell to thousands.
Now, Jira Data Center's outbound mail handling could be better. I mean, it's a project management tool, not an email system, so this does make some sense. So once the queue grows to a certain size, it starts causing problems for the rest of Jira. Not joking; on Jira Server, I've seen this get bad enough to take down Jira. Thankfully Data Center is a bit more robust, but it will still cause performance issues, especially once Jira reconnects to its upstream system and starts flooding emails.
So if this is a known problem for Jira, why can't I see how the queue has grown or shrunk relative to time? This feature intends to give us this kind of insight. And honestly, about time!
Have you ever had a request in Service Desk, and you want to share it with your whole team? Unfortunately, as a user, you have to individually add each username on your team, one by one. Not only is this tedious, but it also increases the chances someone will be left out. This situation could be better.
And that's what the idea is set to fix. Rather than adding everyone individually, this allows you to add your whole group. It is nice and simple, saving time and ensuring no one is left out. Seriously, how is this not already a thing? So Glad to see Atlassian taking this on.
Remember that time I wrote an entire methodology for benchmarking Apps in Jira? Atlassian remembers!
Considering how much I harp on how Apps can impact performance, it will be nice to have some built-in tools to see how an App does against my data set. Of course, how good this is will depend on several factors, including what metrics this exposes, how it's implemented, and what (if anything) it can recommend based on those metrics. Still, it's nice to know I'm not the only one seeing these things.
Have you ever gotten a rejection on an approval you have been waiting for, with no indication of why your request was rejected? Now you have to take time out of your day to talk to the approver and find out what you can do about it.
This idea intends to limit that time sink by giving the approver a comment field to put their reasoning in the ticket. Not only does this close the feedback loop, but it will also allow future approvers to see your justifications to help keep decisions consistent within an Organization. One great thing about this idea is it already includes the fact that an Admin can set this field to be either optional or required, meaning you can tailor it to fit your workflow and requirements. Nice!
In October 2021, I was invited to participate in a charity stream to benefit organizations helping people with handicaps enjoy games. This experience was my first time working with people with visual impairments, and I learned so much about the little changes I can make to make it easier for them.
One change you can make is simply to include a caption for your images. Unfortunately, I'm still working on developing a good habit for this, but it makes your content more universally digestible.
It's good to see Atlassian supporting this by working to include Captions within Blog posts and Pages on Confluence. It's about time!
This feature seems like it wouldn't be too useful at first glance. I mean, when would you ever want to copy a space? They tend to be standalone experiences, right? But think about this:
You can set up a "Gold Standard" blank space that is already set up with the permissions, macros, default pages, etc., to match what your organization would want out of a space. Then, when someone wants a new space, you just have to copy it, and *bam*, you're done. Of course, you might have to set the requestor up as a space admin, but that's minor compared to all the work you just saved.
So, as an older millennial, emojis became popular just a hair after my time. That being said, as a tool, they are a great way to convey context and intention that text alone often fails to do.
That being said, the best way currently to add emojis to your Confluence page is to go to some website, look up the emoji you want, copy it, then paste it into your document. Second to that is memorizing the keystrokes, which is just as painful. So having something built-in to look up and insert emojis will be a massive improvement.
Ever read a Roadmap idea, and felt like it was written for you? I asked Atlassian about our options for a partial Confluence migration a few months ago. We want to move a subset of Spaces from one instance to another. If we want to move all spaces, we can just copy the Database to the new instance. If we want to move just one space, we can export and import it on the new instance. But if we want to move a subset of spaces, that gets tedious. I was hoping there was a better option I wasn't aware of.
I think this is going to help with just this task. But as the description is a bit lean, I'm also making a few assumptions about the intention. But even if it doesn't do all I want, speeding up the reliability and speed of the individual imports will be helpful.
So, one change I immediately note from last year: End User stories! Of course, most ideas on the Roadmap are still directed toward administrators, but this is still an improvement over having near-zero end-user features last year. If your users are going to endure the hassle of testing upgrades, it's worth giving them something for it.
It's also worth noting that the Roadmap goes no further than the end of 2023. Given the Great Server shutdown in early 2024, some people have chosen to read the finite end to the Roadmap being around the same time as an admission that Data Center is shortly to follow. While I don't think DC has an infinite lifespan, I'm not as quick to jump onto that bandwagon yet.
While I'd love the reassurance that Atlassian is thinking about a long-term strategy for Data Center, I'm not surprised that they are reluctant to commit to anything long-term. The economy is rather wild at the moment, and not committing to anything beyond the end of the year frees them up to pivot if necessary.
Don't get me wrong, the writing is on the wall - Atlassian is "Cloud-First," and I still feel they'd love nothing more than to be "Cloud-Only." But I think they will take a while to recover from the fiasco that the Server End-of-Life was before attempting that again. But - I have been wrong before on Atlassian's plans, so I won't be surprised if they prove me wrong here too.
What Roadmap items are you looking forward to? Is there anything you would add to the DC Roadmap? Let me know what you think! I love reading and replying to your comments!
Remember, you can find all my social media links on Linktree. So follow, like, and comment to help the blog grow! I've also been trying to post more on LinkedIn and Twitter, and I appreciate everyone interacting with the new posts!
As far as next week goes, my post schedules will be all over the place. I'm working with Atlassian to get the slides as soon after the keynotes as possible - which is usually the longest part of the Keynote writeup, but I still have to find time to write around attending the conference. (Sleep, what's that?) BUT, I will post multiple times next week - preferably once for each Keynote. I'll also post pictures on social media from the Expo Hall, Breakout Sessions, and Keynotes. So be sure to follow to get the latest from Team '23! Ack! So Excited!
But until next time, my name is Rodney, asking, "Have you updated your Jira issues today?"
Rodney Nissen - ReleaseTEAM
Sr. Atlassian Engineer
The Jira Guy, LLC
Atlanta, GA
13 accepted answers
1 comment