I was a JIRA admin for a number of years for an organization that had a heavy QA workflow. It was all about making sure that every issue had an "owner," at any given time, a strict approval and verification process was followed, and that as much up-front data as possible was collected during the initial report.

In my experience, unless the people entering the issues are paid, professional engineers, we'll never get the information we need up front.

I have found that the basic GitHub model works well for me.

When someone reports a bug, they are doing me a favor. It's in my interest to ensure there are as few roadblocks as possible to them sending a report. If they give contact info, then I can contact them with specific questions.

In my experience, a simple email form is the best way to solicit reports. It may have a workflow hidden behind it, but I have found that the simpler the workflow is, the more likely it is that the issue tracking will work.

JIRA basically starts off complicated, and it's possible to make it much, much worse.

It's also slow, but that wasn't really the problem we had. The workflows and forms were where it fell down for us.

In my experience, it isn't Jira that people hate, it is the horrible rules and bureaucracy-ridden workflows that Jira allows an admin to implement.

My team switched back to Jira after trying several other tools and we're pretty happy.

As a current Jira admin, I constantly have to fight this. A non dev team came into Jira and implemented a huge octopus of a workflow (despite my strong advice against it) and were shocked to find out it didn't really help them work better.

The handful of teams inside that department that I've gotten to switch over to a simpler To Do / In Progress / Done style workflow have been much happier.

Jira has many, many faults, but most of them are what the users do to themselves.

In my experience, it's both.

Jira is laggy as fuck and makes every interaction I have with it take 5 times as long as it needs to, or at least it has been in the two organizations that I've worked for that used it.

We're in what I tend to think of as Jira's pit of despair: there's no explicit support for the on-prem instance; workflow configuration regularly seems to go wrong and has a wide blast radius when it does; nobody trusts the data so we don't get any useful reporting out of it; the UI is... not exactly slow, but I wouldn't call it snappy either; and there's no money for addons that would genuinely help us.

Github Projects would be absolutely fine for us, but we can't switch out because Jira is "what everyone uses" and "has more features", despite us not really using any of them.

All the extra plugins etc. that people bolt in to get those extra features really slow it down too.

If you turn bureaucrats into UI designers, you’re gonna have a bad time. We have several classes of tooling that do just that.

Atlassian tools are particularly overt in their belief that the tool belongs to the managers and not the team. Bamboo especially.

I also don't like JIRA itself, it feels bloated from the get-go.

> JIRA cloud was unusably slow and as a result we didn’t want to use the tool. We hated it even though it technically “worked”.

- every JIRA customer ever

We're a JIRA customer and we're quite happy. It's not slow, at least to any degree that matters.

We're not a huge team, nor do use much more than tickets with FishEye integration though. We also have a self-hosted instance.

But for us it has worked quite well, and I have better memories of JIRA than say MantisBT which I used before.

you are self-hosted, which is different from cloud.

But we're still JIRA customers, which was the point I was trying to make.

Same here - went from MantisDB to Jira and it's a big improvement in so many ways.

Cloud or self-hosted?

Self-hosted, as mentioned.

A lot of issues can be mitigated when you self host vs using JIRA Cloud, not just because you might have beefier hw and better network link. While I suspect it got better, periodic reindexing and similar cron jobs were a hell on a team separated by 9 hour timezone difference, because time chosen for convenience in San Francisco meant many Mondays of "Atlassian Cloud is down" for team in Warsaw.

Wow, that sounds horrible.

While we're all in the same timezone in our company, we're also programmers... so that doesn't always matter. I've been using our JIRA in the middle of the night on several times, and it's just... there.

edit: so yeah just highlights the self-hosting vs cloud...

Not sure what happened to you - but speaking anecdotally, but from someone who logs into Jira Cloud every day, and spends 20-30 minutes interacting with the interfaces over 8-10 hours a day, and has done so for the last 3 years - it's had a handful of outages, nothing that really rose to the level of being memorable though (and less than any internal issue tracker I've worked with) - and the performance is, fine? I mean, it's not <50ms twitch fast, so, I guess I'm losing a minute or do wall-clock time + whatever larger blocks of time that occur when I get distracted waiting for a ticket to come up - but it isn't at all what I would call "unusably slow".

In our case though, we only have about 50 engineers and a few hundred thousand issues. Jira has performance issues in the 500 engineer / 100mm+ issue space - or it used to, perhaps they've resolved those issues by now.

Ours JIRA instance took multiple seconds to load modals. Think 5+ seconds. It was miserable.

I would have gladly paid more for faster speed but it turned out the APIs were blazing fast and it was the JS that was slow. Not sure how we have had such different experiences. Seems impossible that your JS was executed that much faster than mine. I was using chrome FWIW.

I actually got $work to pay for a new desktop computer to prevent me from going insane because of the slugish JIRA and Google Cloud Web Console, and it actually solved it.

My old x260 was not able to run jira/gcp/slack at a reasonable speed due to javascript performance :(

Might be a problem with customization.

THE main problem with JIRA is people breaking it with customization in one way or another.

Or put is on very slow, high network latency servers...

EDIT: Just to be clear, JIRA is never fast. But can be usable if you are not super sensitive to small latency.

The main problem with Windows 95 stability was garbage third party drivers, but we had no problem blaming Microsoft for that.

Really, why wouldn’t you blame the maker of the bed?

If you make a tool that encourages Rube Goldberg machines, then you made something far worse than a Rube Goldberg machine; you built a device to construct them.

> But can be usable if you are not super sensitive to small latency.

Our JIRA instance would lag while typing in the description box. You have to wait a second or two for it to catch up after typing a sentence. It was absolutely unusable.

5+ seconds sounds wild. Our active users number is a multiple of the 5k max users for jira cloud and the only actions i can think of that are >2s are bulk edits and complex jql

We must have been using it incorrectly then, oh well. Good riddance Atlassian.

Almost everyone is “using it incorrectly”, but it’s like the aphorism about assholes. (If you meet assholes all day long, you’re the asshole.)

If your software encounters idiots all day long, you’re the idiot.

I haven't noticed JIRA cloud being that slow, but maybe that's because the team is small.

Did you start to experience performance issues as team size increased? Did you have a lot of issues or data held in the issues? Or was there another issue that you think led to the slowness?

I'm interested in your insights as we went with JIRA initially, since it was pretty much the gold standard and we thought it would scale nicely as we added team members, but if it is not going to do so, then it may not be worth the JIRA premium.

I don't want to put words in OP's mouth, but I suspect that OP was referring to just like... "you click and something and then wait" type of slow. Something like, taking several seconds to load an issue.

In my case, we were a small team (<10 users, <1k total issues split in maybe 8 projects), and were running into random load time slowness irritations. It never stopped us from doing what we needed to do, but it sure did make it more frustrating to do it. We are using a cloud instance.

It’s a documented phenomenon in UX that if an activity involves a quantity of small pauses in a short enough time span, that the user perceives them as a single, long pause.

If your app is fast but your workflows are terrible, people will call you slow because everything takes four interactions. If you have a bad workflow and a slow-ish app, people will talk about you on the Internet.