Based on my experience that doesn't exist.
Hell even if it did, Jira is sooooo unbelievably slow I would still take literally anything else. Maybe even Savannah.
A colleague joked that we need a "waiting for Jira" Jira task.
Based on my experience that doesn't exist.
Hell even if it did, Jira is sooooo unbelievably slow I would still take literally anything else. Maybe even Savannah.
A colleague joked that we need a "waiting for Jira" Jira task.
If it's used for tracking issues, it's great.
If a team just uses it for keeping track of its ongoing work, it ok.
If the team also uses it to plan work, it works less well.
If management also uses it to keep track of what the team is doing, it works even less well, because now the team needs to put on a show for management with the tool it needs to track and plan its work. Now issues need to be phrased in a way so that they aren't causing outsiders to worry. Maybe don't say "problem" or "bug" so often. Use an euphemism. Can't we word it in a less concerning way?
If upper management has a dashboard of all departments' boards, you get nested Potemkin villages where the jira tasks are performative for both middle management, who in turn try to dress things up even more for upper management. At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
This. In my case, it was the whiteboard. It was at a place I worked ~decade ago, where everyone was using Jira for the official work management. That included management, but also included everyone in the electronics production and assembly branch of the company, so it was funny to compare our meticulously described sprint items with co-workers burning through dozens of entries a day, named by just long incrementing numbers.
The M-series single-core speeds were so much faster than Intel at the time that it was noticeably faster.
If I combine our three internal ticketing systems, we end up with something like 200k - 300k tickets, with maybe up to 5M comments on those in JIRA-Terms. If you throw a small-ish, decently configured postgres with 8GB - 16GB of memory at it, it'll keep most to all of that in memory at all times, indexes will be analyzed and fine-tuned to your specific dataset. It will answer queries very, very fast. Any cache in the application servers will also be primed with your data 24/7, speeding it up even further.
JIRA Cloud is most likely not an in-memory problem as a whole at a database layer, so it is at quite the disadvantage performance wise for a small customer.
(In case this turns into a SaaS-Hate-Thread: Yes our customers could have a faster system if they were on-prem. If they had the same experience and expertise running postgres as well as all the other necessary middlewares. And then we're not talking about non-functional operational requirements such as availability, emergency scalability or backups yet)