[grzm]

I agree, and I also know that you have to deal with the world as it is right now even while you work to make it better.

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.

[hchz]

Some people don't want to use it at all, and don't care for the situation that C-suite everywhere buys Atlassian's trash.

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.

[grzm]

And the thread from yesterday (https://news.ycombinator.com/item?id=25590846 for a site named https://whyjirasucks.com) or any of the other many rants on Altassian around the web don't suffice? I hardly think that this thread is going to be the tipping point. It's not like this is news.

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?

[hchz]

(Perhaps I'm not a good person to ask, as I don't work at a product company or in IT services)

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.

[dylan604]

I know this is like well after the conversation, but if you as a developer have to provide Tips/Tricks to your users to be able to use your product, then fix the software to make the Tips/Tricks un-necessary. You don' need to have employees creating accounts on forums asking for "feedback" or "describe for me the steps needed to re-create the issue". You already know the issues with a list of work arounds. FIX THEM!!! This "hey look at us asking the users" is just a sham as they are not even fixing the most basic of things. Why would I believe they are going to fix some thing that needs help re-creating before being noticed by their devs?

[grzm]

If, in your opinion, the situation is so bad that it's a sham, why comment on this at all? What will that do to make the situation better, for Atlassian, for you, or for anyone else reading the thread?

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.