There's lots, but I think it comes down to two main things: It has bad defaults, and it can be customized to have really draconian workflow rules.

If you configure it to be reasonable -- keep the workflows very simple with few to no validation rules -- it can be fine to use. The temptation seems to be locking down admin access to managers, and then the admins going crazy building workflows like "these 19 custom fields must be filled out to start" "items must go through a QA step" "QA users are the only people that can approve that step" and "PMs are the only ones that can close a ticket". This quickly gets out of hand and makes it horrible to use.

It also depends on the people using it -- garbage in garbage out, as they say. If people write good tickets (concise titles, format the body, remove irrelevant crap, and properly fill out meta fields like fixVersion) it is much more useful. JQL is awesome, and embedding tickets and JQL queries of tickets into Confluence is awesome (hint: easy way to make release notes) -- but both of these require non-garbage ticket content.

Subpar at what it's supposed to do, extra features don't add a whole lot, mostly made and configured for managers instead of developers. Largely the same reasons people dislike Teams. Has even worse integrations with the Atlassian stack than Teams with the MS stack.

JIRA, just like Teams, is slow, bloated, still won't fix basic issues and largely exists to appease managers. You have to actively work to make JIRA a pleasant experience. It's too easy for most management to make it hell.

I personally find that the more I have to use JIRA, and the more magical ephemeral rules that are set up in it to take actions in response to my actions with it, the more terrible it is to use.

I've worked on teams where I just threw info into a card, and it was acceptable to use, and I've worked on teams where commits had to have a JIRA tag associated or the commit got rejected, including in instances where bitbucket was timing out it's call to JIRA. In the latter cases, I prayed for Atlassian's swift destruction, but alas, was never answered.

So like a lot of tools, it's how you use it, mostly. That said, as far as universal problems, cloning cards has to be one of the worst UX experiences I run into on the job with any frequency that I can't just fix myself. If the web app needs to await a successful or failed clone of a record (or series of them), I'm not sure why they can't implement a modal or a spinner or other component to tell the user that something is happening, then either navigate the user to the new card, or ask the user if they would like to view the new card. Shooting off a process that you say could take an indeterminate amount of time then dropping eventually a completion notification and link in the bottom left panel is just about the least helpful way to communicate that information.

edit: unrelated meta comment, but it's funny as hell to me that this question got 4 replies in the few minutes it took me to write this reply, all within 10 minutes of the original. People are really out here just waiting for a chance to complain about JIRA. Myself included it seems. Makes me feel a bit bad, hate to pile on to popular sentiment when others have already commented in a similar direction.

I'm trying to cleanup a Git tree right now where people haven't put JIRA tags in their commit comments, it is impossible to find out why a change was made, it isn't a totally stupid requirement.

"It's impossible to find out why a change was made" is a completely separate issue. Either the code is documented or it's not, completely polluting your history with JIRA tags isn't the answer - not least of all because like a sibling commenter said you're now forever tied to JIRA, or if you ever move off of JIRA, now get to choose between bringing JIRA tag information into the new ticketing system, or rewriting your entire git history again.

It's definitely a concern to rely on the ticket system, but the commit message and the comment can't (and shouldn't) contain every bit of info about a change.

Commit message: "Improved clarity and detail in error message"

Ok, that's obvious what's happening, and as a standalone change that's absolutely fine. But the question it doesn't answer is why did someone actually put that effort in?

If the commit message mentions a ticket, then you can go look that up, and now you can find out, for example: it was a ticket that was an unknown bug being experienced by one specific customer, and so the error message was being improved as part of tracking down the bug. You also see who the customer was, internally who reported/escalated it, how long this has been an issue for, and if the bug was found and eventually fixed or not.

I'd argue absolutely none of that belongs in comments in the code, and it's way too onerous for a dev to constantly put that level of detail into every commit message. It's a balance: it's only useful to lookup that info on a small fraction of commits; it takes a lot of time to figure it out when missing (especially if it was many months ago); and putting a ticket number in each commit message is very low effort.

The project has just moved to JIRA from Bugzilla. The original convention was to put the Bugzilla issue ID in commit comments, these IDs were carried forward when moving to JIRA so people can still search for them.

Yes, "let's tie our codebase to the choice of ticket system forever as a means to commit documentation"

You can have both. Also, let's not pretend developers are wholly committed to writing comprehensive commit messages. A ticket number is useful if the change was relatively recent. If the organization moves to a different tool, chances are they are well aware of the potential history they are leaving behind.

and... I've never yet been in a team/project where being able to track/view/find issue/code pairings from years ago was ever remotely useful or helpful. If it was something in the last few months, sometimes people could dig in and try to understand a bit more by asking relevant people.

Finding a 'bug' introduced by someone from 4 years ago who doesn't work there any more, then finding the particular ticket that spawned it... this has never been high on the priority list of anyone I've ever worked with.

As an architect working on maintenance & refactoring, I find regular value in being able to understand the context (issue tracker ticket) in which a commit was made.

Also more than mildly useful for devs doing porting work.

Commit comments are rarely substantive enough, and "asking relevant people" is nice but not an actual substitute for keeping meaningful records.

I can recall multiple times I've determined why the current logic in the code should be not simplified as part of refactoring or fixing a bug after tracking down the original ticket associated with a commit. That original ticket is quite often a bug report, and sure enough, there was actually a good explanation for why the code is written the way it is, which is almost never going to be captured in commit or inline comments. While having an associated unit test is arguably a better way to capture the reason for such code changes, there are many reasons that's far less likely to exist than a JIRA ticket or equivalent.

So people put the ticket number in the message and then don't write a useful commit message. Congratulations, you just added one roundtrip per commit to the slowest website in existence to every single time you want to look at git history.

Did I mention that you can't look at JIRA from a mobile phone?

This assumes that writing a ticket causes people to explain their rationale better than a commit comment does. That might be the case, but it often isn't because tickets are filed by developers themselves, or by PMs who just write tickets like: "A system requirement is that users be able to do X" without further explanation.

Or you just write sensible commit messages. Commits together with the messages should require as little out of band information as possible.

Bullshit. "Fix performance issue in listing page for customer support".

Which customer? Is it the same issue as the one this other customer is reporting? How does the support person know the fix has been released?

Unless you are expecting devs to copy paste a tonne of info into commit messages, it's way easier to just put the god damn ticket number in the commit title.

If you really need to commit something with no ticket, just have a dummy ticket placeholder like DEV-0000.

99/100 it's just laziness on the devs part... It's way easier to add a ticket number than write super detailed commit messages, and every case of missing Jira numbers of seen, there has never been a detailed commit message in its place... /Rant over

> Unless you are expecting devs to copy paste a tonne of info into commit messages, it's way easier to just put the god damn ticket number in the commit title.

Yes, that's what devs should do. Or link to an issue from the git provider. Commit messages shouldn't contain customer information, they should contain fine grained information why the change fixes a particular issue and other technical minutae.

What you doing here is conflating business information and technical information. Business knowledge has no reason to be in commit messages. The code base should be 100% understandable without specific knowledge about what customer wanted what. It would be a huge red flag for me to see those things talked about in the context of the commit messages as a regular thing.

I hate to break it to you, but code is usually written in support of a business objective and does not exist in a vacuum of technological purity... I say this as someone who's written everything from x86asm to python and everything in between for decades. If it really upsets your sensibilities to insert a reference to that business objective in a commit message then I don't know what to tell you...

A business objective is generally translatable to a use case, user story or requirement that can be understood without knowing "Mr. Smith from Company Thingamajig struggles to do x and is willing to pay sums of money to have it fixed". Your developers absolutely should NOT be knowing or dealing with business objectives.

As always there can be exceptions but if this is normal operating procedure for your company I would run far and fast.

> If you really need to commit something with no ticket

I'm of the opinion the only time this should ever happen is if it's a critical fix to allow ci builds to succeed. E.g. unit tests with hard-coded assumptions about the external world (current date etc.) that stop being true. Or errors in pipeline scripts that occur due to changes in a build agent.

The best thing about cross-linking between Git and an issue tracker is that when you have multiple commits for one ticket (very common), they can all link back to one ticket. Having the extra context from discussion is useful, but obviously that can be summarised in the commit message. So being able to instantly get a list of commits that link to the one ticket is the really invaluable feature that I don’t know of any good way of doing another way.

I'm a big fan of this personally, but I've also lived with the experience of completely useless commit messages, so I understand both arguments. Here's the most recent commits for a project I'm working on:

Counts

Counts

Counts

Counts

Log entries

missing package json

missing package json

ttl in seconds

cache back on

Still, I'd rather try to convince people to write useful messages than hard bind my remote code repository to my system for managing work, and often times (but certainly not always), single line commits are self explanatory.

Jira doesn't really work well out of the box. It needs a lot of work to configure. I love Jira now, but it's been hell in the other startups. It's probably why stuff like Trello and Asana took off.

JIRA implementations I've seen don't help people see what's ahead; they focus on what's been done to date. If you're on a single, small team that has minimal dependencies on other teams, that can work, but if the project has any significant dependencies on other teams, it becomes very hard for anyone to understand how things are going.

That’s literally the point of the kanban board. I don’t understand how these projects were configured for that to be true — did they hide the backlog?

Atlassian is an asshole company for their stance against selfhosting it.

What stance? You simply purchase a license and selfhost it.

See https://www.atlassian.com/migration/assess/compare-cloud-dat...

Newsflash: Jira Server end of sales was in februari 2021. Support will completely end in februari 2024.

You better start scheduling your migration.

Maybe for insane prices. But that too will go away.

People that don't need Jira but are forced to use it just hate it.

Same as any other product in the world.

What's good about it?