Linear – A fast issue tracker

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.

All issue trackers can be placed on a spectrum: one end is occupied by very fast and very simple apps, another by complex and flexible ones.

Fast ones win in the ease of creation of an issue (just type and hit enter), and generally feel more sexy and attractive, but complex ones can be set up to the exact workflow you need.

For example, Google tasks or now-dead service do.com by Salesforce clearly belong to 'easy' end, and software like Redmine to 'complex' (though it can be made to look rather attractive by the use of skins).

For us, we're sticking to redmine, because it is good and very extendable by the use of plugins. We've found that ease of use does not cover for the reduced flexibility.

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.

Slightly OT thought, but related to ticket tracking systems and the idea of reduced backlogs:

As we move more and more towards ubiquitous "Product Orgs," separate from engineering, I think we're seeing backlogs just explode in size at most places. People need to realize that a large engineering backlog has a lot of negative effects on the SDLC (& velocity) as a whole. I wish more people would embrace heavy-handed WIP limits, even for backlog.

But, since backlog is now the primary output of "product orgs" at many (less-than-great) companies, you now have an entire org whose jobs depend on not learning that lesson.

I don't know what the answer is, but I really am starting to hate this entire "product org" concept in general. It feels like we used to be able to just engineer our way around many of these challenges ("here, look what I built last week to justify my case"), or just get people into a room and talking. But once the decision channels become explicitly siloed off into a separate org with C-Suite-level autonomy, I'm not sure how you effectively bridge the gaps that form.

Any engineers who feel like having a separate product org has been a benefit to your company's product quality and delivery speed want to comment on how you see this sort of thing working effectively?

Hello. Looks good on the screenshots, I'd love to try it for my team but the signup link somehow sends me to Google instead of signup. /s How do I try it?

On a side note, I use Edge on a Mac and the signup page doesn't detect my browser as compatible; it's just Chromium inside, must be totally compatible with everything.