Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

FWIW, check out the new Reddit interface. For all the well-deserved hate it's getting (some of which for the same reasons Jira is), it showcases that you can have a dual WYSIWYG/Markdown editor that works, and allows switching back and forth between modes during editing.

The biggest request I have of JIRA aside from performance is that whatever markdown/markup language you choose, that it be consistent across the entire product.

It is so frustrating to have to remember to use double-curlies for inline code/pre sometimes, and backticks other times. In each case, the other doesn't work. More than once using one has resulted it rendering correctly on the immediate page but not on the next.

This is one I encounter regularly but is far from the only inconsistency in support.

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?

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.

Right but as QA you can make a ticket but unless you assign it to someone who supervises all those departments it’ll just get closed as “works as expected from where I’m sitting at department A”