[aetherspawn]

OK, we are firmware developers who use JIRA in a very advanced way with our clients, and we gave it a go and I just came back here to give the team some feedback because no doubt they are watching this very closely.

The killer missing feature for us is that we can't define different issue types. For example, we would typically have issue types like "Requirement", "Bug", "Signal", etc. with different icons and use child/parent hierarchies to sort these in a tree with this hierarchy: L1 high-level business requirement, L2 technical breakdown stories, L3 very specific requirement/bug/signal.

In line with this, there's no way to show the issue layout as an expandable tree-view (called "List" view in JIRA), and so our requirements tree would get all mashed up and flattened.

For each technical story/signal we would have a custom field where we set the source file where we are implementing it. This would help us hammer out the architecture of projects very quickly and have them line-up with technical requirements. Doesn't seem to be a way to add custom fields to different issue types. Later we would export this all out of JIRA to help write our documentation.

Lastly, a JIRA replacement without a corresponding Confluence replacement could be a bit of a point of friction. I hope that somewhere on your roadmap you plan to develop a basic solution to cater for the Confluence need.

Otherwise ... it looks nice. Have you thought about offering a self-hosted version, since JIRA no longer offers this?

[hn_throwaway_99]

Actually, I think your post highlights a couple important things:

1. The reason everyone hates Jira is because, over time, it has essentially become all things to all people, yet it doesn't solve the needs of any individual group perfectly. It actually has a huge, ginormous feature set, and part of the difficulty is figuring which settings or set of features are right for your team.

2. The reason Jira has become so difficult to replace is because nearly every team of moderate complexity uses some subset of features that aren't replicated in any other tool.

So, to the point, I hope that Linear doesn't implement your requested features (not exactly, but I just hope they are extremely judicious in which features they add). Or, rather, I'd just point out that Jira got to be the way it is because they basically implemented all the features. I think a good competitor will necessarily have to hit that sweet spot where they have 98% of the most critical features (especially startups/new companies), but will ruthlessly not add features that will lead to bloat and complexity.

[lmm]

> The killer missing feature for us is that we can't define different issue types. For example, we would typically have issue types like "Requirement", "Bug", "Signal", etc. with different icons and use child/parent hierarchies to sort these in a tree with this hierarchy: L1 high-level business requirement, L2 technical breakdown stories, L3 very specific requirement/bug/signal.

Support for this kind of overcomplex use case is what makes JIRA so horrible to use. I very much hope Linear never bloats itself by adding this kind of thing.

[aetherspawn]

You'd better hope that enough people need a very barebones tracker (thousands of barebone trackers exist) enough to pay for it and keep it alive. Or you can implement the "overcomplex use case"(s) and create a product that is actually more useful than those other thousand of issue trackers built-in to tools that people already use.

[solardev]

Hell no. If you want jira, use Jira. Linear is better specifically because it's not Jira and doesn't try to be.

A huge part of its appeal is that it actively prevents workflows like yours. On purpose.

[Arcanum-XIII]

I honestly despise Confluence. Jira is kind of OK if you don't create overly complex workflow (they will fail) and avoid using it as a documentation tool (it's not versioned, editing tool are lacking, adding content is quite limited, updating content while fighting field is not fun and finding back the last CR related to a feature is hell).

But Confluence is the worst Wiki I've ever used. It's editor is obnoxious, it's so damn slow, you're losing edit whenever anything happen, tagging is quite often random (recently it added an unwanted "my.favorite" tag to page I'm copying), it's search is broken since the beginning, hierarchical view is broken, creating add on requires to be a high level admin and the implementation is horrible... And I've been forced to use Confluence for 10 years now, in multiple company. None was ever good with it. Heck, here people are screaming to go back to Sharepoint.

[freefaler]

I've been using Confulence for a long time in all my companies. It's not the best product for sure. However, regarding: 1) slowness - it's faster selfhosted than their shitty cloud solution 2) editor - one of the best features, not replicated anywhere is their macro collection. I'd prefer markdown, but dynamic object embedded in our specs/documentation is a very useful feature. Also for non-technical people their editor even in current state is easier than other non-WYSIWYG editors for sure.

There is a place for a competitor to Confluence, because the need is still there. Help non-technical people capture and buld documents self-hosted inside your firewall with dynamic elements.

Atlassian's decision to dump the self-hosted version in 2024 will create the niche for all the companies that would want to migrate away. They just got greedy and got too big, went public, founders cached out and now it's the hired managers playground.

[hiyer]

They've (recently?) introduced a feature where they disable the editor window in Confluence if the browser even momentarily loses the network connection. On a poor network it's absolutely unusable now.

[solardev]

This is the sort of workflow that makes Jira suck... so much mental capacity is wasted on categorization rather than coding. It simultaneously tries to be an issue tracker and a project manager and each team reinvents their own preferred workflow while littering the shared Jira graveyard with a bunch of dead fields and labels and screens and such.

Linear does the opposite, adding rails so you can't go wild and reinvent complex processes. Thank god.

[aetherspawn]

We didn’t invent this workflow, it is mandated by high assurance software standards like ISO 26262.

[solardev]

Sounds like a good category of software to avoid :)

[rjzzleep]

When you say very advanced way do you mean Jira workflows? Or do you mean more than that?

[dbbk]

On the Confluence note, they do have docs support: https://linear.app/docs/project-documents

[jwr]

Wouldn't tags for for this? It's similar to how I use them.

[aetherspawn]

We could use tags for this, but with an issue type hierarchy you can strongly-type your database i.e. make sure that people don't put a Signal under a high-level business requirement.

And different issue types in JIRA allows us to have different workflows and optional fields for different types of issues, ie in the use-case above the Requirement field has an extra field to mention a corresponding document and most of the issue types except business requirement have an extra field to fill in the source file where we will implement it.