Ticket Management by Bluster
I gave up on ticket management software long ago. Nothing works, really.
I now run my teams on a manual system: CRMs, support personnel, integrators and the upper elite of the user-base feed "issues" in via the usual dodgy means -- usually a badly scanned, upside-down monochrome photocopy of an iPhone displaying a photograph of the screen, half obscured by a shadow, with half a word edited on in hotpink mouse-hand via MS Paint -- and some poor sod collates those and manually curates a backlog of issues in the form of a good ol' spreadsheet.
The team survives. Every few months, someone wants graphs and numbers for some management presentation or meeting or drumming circle or whatever and we make those up -- also in a spreadsheet. The team performs well enough that nobody ever challenges them anyway.
Find and fix your own bugs before release -- it's quicker than fighting with Jira's bugs after.
Isn't it ironic that, after decades of work as an "architect", all that knowledge of frameworks and libraries and languages and platforms and "paradigms" and next-new-things has gone as quickly as I picked them up and dropped them and, in the end, the only thing I've really become better at is testing?
"Why build it this way?" they always ask. "Because, if it's broken, it'll explode in spectacular style and we'll know about it," I always answer. "There's a package that will save us these 60 lines, can't we use that?" "No. Those 60 lines are trivial and can be 100% covered by tests with a `for`-loop and some randomised data. That package does everything under the sun and has 2000 open issues on their github page. Which do YOU want to debug?"