I also got no response (or even an acknowledgement) for the feedback I gave. Like most people here, I too am forced to use it at work.

(edit: looks like HN is severely limiting my reply rate so apologies for delays)

it is more like a general feeling all the time for many of us.

I'm using the latest Firefox on Windows, a developer laptop with 32GB memory that was brand new this spring as well as 500/500 fiber.

Right now on holiday (through Tuesday), but would like learn more. I see your contact info in your profile, if you give consent I'd like send you an email on Wednesday with some followup questions (the first question is "what is the URL for your cloud instance" so I don't want to be asking for it on a public forum)

(edit: typo)

On my company's cloud instance of Jira, it's a minimum of a 2-3 second delay to do anything. Edit, wait a few seconds, save, wait a few seconds, change a field, wait a few seconds... and God help you if you need to reload the page because something got stuck.

Sometimes things are just obviously crap to the people tasked with working on them and having to jump through these kind of hoops eventually leaves an organisation with only the kind of people who are happy to keep doing it.

Nothing makes me stop ignoring recruiter messages quite like being asked to flesh out a JIRA ticket with technical details by a person who has literally no use for the details they ask me to write.

Atlassian employees use their products, and tips and tricks they may have to use them effectively, or make the experience of using JIRA or Confluence, or their other tools more enjoyable and useable would be great to know!

If you have to use Jira or Confluence at work, you probably want to know how to make that as useful as possible. If you're working at Atlassian, you probably want to make your customer's experience as enjoyable as possible as soon as possible. Ideally you have a great product and great documentation and all happy customers. If that's not the case, you have an opportunity to work on a number of fronts, including improving documentation and the product, and help current customers with the product as it is. You can and should be doing all of these things.

Piling on doesn't help anything.

They don't want minor improvements to help it limp along, they want to vent and complain about it.

I think it's impossible that Atlassian evolves into a good product company, but it's entirely possible that my next CTO googled for opinions on the product, found a few discussions on HN with a combined 3,000 complaints about what a garbage fire it is, and went with Clubhouse.

Given your opinions regarding Atlassian, what would you think of your next CTO if they were even considering Atlassian? Is that someone you'd want to work for?

I really wouldn't give it a second thought, as everybody is using this stuff.

In my niche, there is very little focus on this kind of project management, due to the required speed of development and deployment.

If you work fast and reliably enough, delivering commercially important software, nobody is asking about a JIRA ticket.

My original point was that people should engage with each other in a way that's likely to create the most positive outcome. Creating throwaway accounts so one doesn't need to take the effort to be polite or take the time to be explicit about what they mean in a low-bandwidth context like HN is, in my opinion, highly unproductive and lowers the discourse on HN. If we're not trying to make things better, both the particulars of the situation (say, figuring out how to make Atlassian products easier to use) and put us in a better place for solving situations in the future (maintaining HN as a community people want to participate in), I don't think we should comment at all.

The throwaway I responded to hasn't participated further, and everyone else seems to have focused on the "tips and tricks" phrasing I employed, so one last attempt to elaborate:

Hypothetical scenarios:

1. You have to use Atlassian products at work for reasons that are out of your control. Your options:

- figure out how to make using the products as easy as possible.

- refuse to use the Atlassian products

- figure out how get your organization to change to another product.

- find a new job.

I'd argue only the first one is in your control as something you can do today on your own.

Some options for "figuring out how to make using the products as easy as possible":

- Complain on a forum that Atlassian products suck. The venting may make you feel better, but won't really improve the situation.

- Engage with an Atlassian employee

If you don't believe Atlassian is going to actually do anything, you might as well not make the effort of engaging at all. If you think there's a possibility you might find some relief by doing so, set yourself up for success. Snark and aimless, general complaints are unlikely to lead to a successful outcome, and I think it's likely to actively increase your likelihood of failure.

2. You're an Atlassian employee.

Note: If you don't believe Atlassian employees are operating in good faith, you can skip this section--and, for that matter, everything here. Get your company to switch tools, or quit.

Atlassian developers--just like any other developer--want clear, reproducible bug reports so you can fix the bugs (including slow performance). You want to know (a) what they wanted to accomplish; (b) exactly what they did; (c) what they expected to happen; and (d) exactly what did happen. If you want support, supply this information even if they don't ask for it 'cause that's what they need.

Fixing bugs takes time. Adding features takes time. Improving documentation takes time. All of those things should definitely be done. If the fixes are trivial, of course prefer the fix over the tips and tricks. If "tips and tricks" can work as a stop-gap to while these other things are worked on, by all means Atlassian employees should offer them and those using Atlassian products should use them if they want some relief now.

Time is a finite resource, and you need to figure out ways to move forward the best you know how. Your customers are likely diverse and have while they likely share some priorities, others are going to be different. Choosing to fix bugs A, B, and C while moving forward with features M, N, and O means that bugs D, E, F, G, H, and I and features P, Q, R, S, and T aren't going to be worked on, at least right now. And your customers that really want A, B, and C fixed and your customers who want features M, N, and O are going to be so grateful, and your customers who really a bitten by bugs D and F are going to be out in the cold, as are customers who want features P and Q. But if you can give customers affected by D a workaround in the meantime, I think that's better. That's just how things are, at any shop. And not just in software development.

If your priorities as a customer don't line up with those of the company whose product your using, your options are to wait, find a workaround, convince to the company to reprioritize, or find another product.

Focus on what you can do rather than what others should do. If you rely on the actions of others, it's still the same: what you can do to help others do what you want them to do--in a way that maximizes the likelihood of success.

The short version of all of this is engage with each other in good faith. If you don't believe the people you're working with are doing that and you don't think you can change it, it's really not worth continuing to engage with them, positively or negatively.

A key distinction is between domain complexity and what the product adds to that intrinsic complexity. If you use GitHub or GitLab issues with no customization you’ll have a better experience than a Jira user because they work well out of the box without requiring customization or adjusting your workflow just to accomplish core tasks.

On the other hand, I do not view those systems as products when it comes to professional use. A non-techie might see a Mac as a fancy laptop but for me it's a tool. Just like an HSS cutting tool in a lathe, you'd carefully maintain it (you don't want to use a dull cutting tool) and tune it. Just like you want to regrind a cutting tool depending on the part you are machining, I disable Intel Turbo Boost using http://tbswitcher.rugarciap.com when I run long perf evaluations of my programs for academic projects. If M1 based Macs will not allow me to disable their boost clock functionality, they will be unsuitable for my work as a tool. When that happens, you simply pick the most fitting tool. Not necessarily switching dev platforms, in this case a separate machine running Linux for the eval may be OK.

Regarding issue trackers, there are still some things I miss about Bugzilla after moving to Github issues such as sorting issues by two fields in order (eg first by prio and then milestone). I similarly like complex queries that can be saved in YouTrack. I will admit that 5 years ago I thought that Bugzilla was ugly (it still is) and not user-friendly (one of the worst) but now I simply see it as a professional tool that does not get in my way once I learn how to use it. On the other hand, most of the tools with proper UX (not all, most notably airplane cockpits have proper UX but still do not get in the way of a pilot doing their job including manual overrides for all kinds of malfunctions) have some "user journey" which gets in the way of almost every pro user.

What do your metrics show? I instrument my web sites so I know how long every operation – server responses, front-end JS changes, etc. – takes and can guide my development accordingly. You have a much larger budget and could be answering this question with hard data.

I’ll second the “everything” responses. Request Tracker on 1990s hardware was considerably faster than Jira is today - and better for serious use, too.

We have metrics, but of course as with many such things you always want more insights than the amount of data you're collecting (so we're always trying to grow this as appropriate).

This data is what led to the above (added edit trying to reply to @rusticpenn) saying we can see that "some instances are slower than others", and "some users are slower than others". I can't share those numbers of course though.

However, privacy reasons does prevent us from collecting too much data, so differentiating why individual users might have different experiences (even when other known factors are similar/identical) is difficult.

Also I'd be happy to take any suggestions you have about what to look at back to my engineering team, if you're willing to share other ideas. I know we're tracking several of the ones you mention but more options is always better.

Thank you for the advice - how about on the page load side? Our biggest problem is probably the variance issue (mentioned in other subthreads) -> we can't easily tell what is the difference between a slow and a fast load in many cases.

Even if we compare things that are available from the metrics like CPU, Mem, and Network speed, those are not very granular metrics (for example, to understand someone with 16 threads was actually at 95% Mem used during that page load), and have little correlation at a wide level with page load speed.

It is not your customers job to instrument your software. Your API gateway can provide precise and accurate figures on how long API calls take and there is nothing stopping you adding web page metrics that can provide client-side measurements as well.

Some examples are available on the publicly visible JIRA boards, like the one for hibernate. Just go click on all issues and then click on any issue in a private browser window and with the cache empty.

Every one of the fields take seconds to load. That is not internet roundtrip time, that is your backend. Even when the issue is ~80% loaded (according to your own page load bar), there are still JS scripts that will load and reformat the page, causing the browser to reflow.

These are not cached, because loading another issue doesn't resolve the problem.

So there are fundamental front end problems that have nothing to do with the servers or backend, they are entirely a problem of the JS and the in-browser activities.

Fix them.

I am sorry, there are probably customers who are used to the tools. Maybe they don't pass the Mom test. That point comes out as unnecessary defense here.

Can I suggest following up with those customers to see if and how they're using the product, what's their computer configuration, if there's anything special about them?

"This is very slow"

"We have no problems"

These aren't addressing the same things, really (unless the OP was translating "we're happy with the speed of the entire system" as "we have no problems").

Are the people reporting "no problems" actual end users. People I know who've become acclimated to Jira that I know would happily respond "we have no problems" while the people below them who have to use Jira 10x more often (multiple times per hour, vs a daily look at progress, for example) would happily say "this is slow as molasses (and that's a problem)".

Persistently asking for particular workflows, as you've been doing throughout this thread, shows a failure to understand the scope of the problem. In fact it makes me wonder if your paycheck depends on not understanding it. It sure seems like someone's does.