[Calzifer]

Great, a few more decades and it might become a usable bugtracker.

What's next on the list? Maybe priority/severity or status/resolution?

I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.

[IshKebab]

> well administrated Jira

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.

[marginalia_nu]

I think 99% of the problems with Jira stem from trying to use it for too many things at the same time.

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.

[TeMPOraL]

> 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.

[rplnt]

I believe Apple silicon has Jira coprocessor. It really became usable on M1 and beyond. Even the horrid UX got somehow better in the last few years (like not having 3+ different text inputs, each with different formatting behavior). My guess is since the hardware caught up with them they can now finally use it and iterate.

[jonpurdy]

You jest, but I tested this and it turns out that it was JavaScript, not slow networking, that made Jira so slow for me. (I was trying to figure out how to locally cache assets to speed it up.)

The M-series single-core speeds were so much faster than Intel at the time that it was noticeably faster.

[aklemm]

"Apple silicon has Jira coprocessor" time to retire to the country and raise chickens.

[hadrien01]

A well administered JIRA can be really fast. There's a reason Atlassian themselves don't use JIRA Cloud: https://jira.atlassian.com/browse

[IshKebab]

Huh that is much faster than Jira Cloud. How come though? Do they just hate their customers or something?

[tetha]

I don't have practical experience with JIRA Cloud Operations, or JIRA on-prem operations, but if I compare on-prem vs SaaS of our own solutions, the answer is scale and focus.

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)

[originalvichy]

My guess is that self-hosted versions have an infinitely simpler user experience when it comes to accounts and visibility. Jira Cloud is definitely angled towards always being behind some sort of an account system, which used a real, costly backend, but the self-hosted one can get by with the local hosted IdP or an LDAP server.

[dotancohen]

Take a look at Redmine. It's a self-hosted Ruby project manager and I love it, especially for issue dependencies.

[IshKebab]

Nobody who uses Jira is really in a position to pick anything else.

[lukeforehand]

Even years ago Jira was too complicated, to the point that we joked about replacing it with a physical notebook.

https://thedailywtf.com/images/200802/manualJira.jpg

[badgersnake]

Indeed, see https://ifuckinghatejira.com/

[StableAlkyne]

> Maybe priority/severity or status/resolution?

That's already possible with the tag system. At least, that's the most common use I see for repos that decide to use tags.

How do you envision this differing?

[akoboldfrying]

Are you thinking of labels?

I only know GitHub "tags" to be the raw git branch-that-never-moves kind.

[ffsm8]

Totally off topic, but Tags can be moved too. ;) It's mostly a convention that we use annotated tags (a tag that also creates a commit) and don't move them

[smarx007]

Sorting by priority?

[chrisandchris]

Transitioned from Jira to Gitlab. Jira has workflows/resolution states. Gitlab only has tags.

It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).

[rbetts]

Using Github issues as a manager of multiple teams using multiple repos in GitHub has so many gaps, I often wonder if I'm just doing it wrong. The multi-repo issues feature a few years back was a huge step forward but also is very incomplete, still. Multi-repo labels and milestones, for example, are an obvious missing feature.

[lmeyerov]

Exactly this, they are so close!

[sangeeth96]

I really feel like GH needs to spin out Projects into a more dedicated, funded team while still maintaining a close sync in order for it to become more viable/interesting. Besides allowing it to grow faster and better, that should also allow for non-dev seat pricing.

[TeMPOraL]

IDK, but maybe, for the sake of people working in projects that are managed using Github/Gitlab issues, they'll spin off a separate "Tasks" features and allow to set dependencies on them.

[FridgeSeal]

Jira is so abominably slow, that it should be laughed/shamed out of the room in any discussion of useful software.

[treyd]

Yeah I have no confidences in GH to become viable for issue management for large commercial projects.

It works fine if you're a group of highly competent and aligned FOSS developers that need it more as a communication tool than a work management tool. But if you get to breaking work down to the level of a few story points it becomes completely unmanageable. The table view turns into a slog if you have more than like 70 tickets.

[bastardoperator]

They're called issue labels, go read up because your complaint isn't valid.