The biggest problem I have, by far, is just how easy it is to create bureaucracy-intense workflows in JIRA and make management believe these are absolutely necessary. Most developers do not need this info, and do not have the power to easily change things. All the fields when making a simple ticket, the dozens of sub-tasks, the ticket inside a ticket inside a ticket. I would believe this is not impossible to avoid, but I do feel a simpler structure using labels, milestones and issue tracker is far, far easier and less prone to being misused. GitLab and Github can both do this as far as I know.

And sure, JIRA integrates nicely with other products (Bitbucket, Bamboo, Confluence). Other products have these integrations on a more modular level and still load faster and have small QoL differences over JIRA. Maybe big corps need a bit more, but JIRA seems to be too focused on managers and suffers from feature creep to the detriment of user experience.

Omg, finally someone has said it, I thought I was weird. This is the imperative problem with JIRA, it is not made to help the developers but to satisfy management which is buying the software. +1 for this comment. I have seen its usage in 7 companies and in each and every case instead of simplifying developers workflow it was complicating it due to management wanting to have their data which, at the end, didnt bring anything for the product but were just enabler to make their cute graphs that enabled them to not be involved into development cycle (as they should be) but rather bring out statistics "out of their shoe - JIRA".

And this is also my only (ok, except the slowness which should be understandable for any web browser js application) comment over the JIRA, I dont care what the tool is, how much time it takes (at the end, I am not paying for it), but how much it diverges from the tool that SHOULD help the development while in its essence it mostly helps the management to track their data.

that's mostly down to the current JIRA configuration, same with the workflows used. One thing that I found great at my current office was letting the team configure their Jira projects as they wanted

I would love to see the insides of what we have configured, and toss the junk out. It ain't happening in the next 20 years, and I sure as heck don't plan to stay that long at a company putting little value in the experience of its employees.

In the Atlassian ecosystem, the markup languages are constrained by the following equation:

   JIRA Markup != Confluence Markup != Bitbucket Markup

- backticks when creating a Jira ticket, e.g. `hello`

- double curly-braces when editing a Jira ticket, e.g. {{hello}}

... or vice versa. I cannot honestly remember which way round it is. Of the complaints I have about Jira this is probably the least annoying - but it really shows how irritating the product is.

I remember this caused me some data corruption when editing a comment created with the old version of the editor using the new editor. It was a mess.

As many others have mentioned thought, it is abysmally slow. At least their Cloud offering is, which is the core product we use at my job. I've used older on-prem deployments though and they were lightning fast. Seems that they're deprecating this solution by 2024 though.

I recently completed a JIRA survey, and slowness was my number one complaint. Hopefully the Product teams read through those surveys or peruse HN. Everything else about JIRA works great for our Software Development needs.

Holy hell, what a tragedy. I used to write markdown and have pandoc typeset a pdf in the company design. Now I have word.

Any suggestions for that similar synergy? Doc/Issue Tracker/Code base integration?

To me, tracker is an easier user experience for focusing on a stream of stories. And a more streamlined experience for work assignment means more time writing code to solve problems.