[desc]

This.

Jira is a framework for building something which approximates your actual processes.

> Justin said “I wish Atlassian would sit down with real-world developers and design this product the way we need it to work.”

The way 'you' need it to work. The process 'you' use. I suppose it's possible to build a business on creating a completely bespoke ticketing system for each company which uses one. Over time, that business might gravitate towards building a general toolkit which can be configured for each use case...

Oh look! Jira!

I'd bet that everyone's got their own distinct idea of where subtasks, ticket relations, etc actually fit in their workflow.

The article clearly exists to sell LinearB's product, which will of course work great for people who have the specific problems LinearB are solving with their product.

The rest of us will configure Jira within epsilon of 'works', then spend an afternoon reading about APIs and bash out our own automation service to update X different management tools appropriately for our workflows, and then go down the pub to bitch about management.

[Supermancho]

I'm not sure why nobody provides a task tracking tool that has tasks organized hierarchically (with chord/circular dependency. This is the real world, regardless of the argument about subjective processes. If you can't see where in your workflow, that 1 task (even from another team's workflow) is impacting multiple other workflows at-a-glance, the tool is too primitive. Subtasks don't cut it.

JIRA is the most popular of all tools on the market, which are glorified gantt points across disparate fragmented views. This is an element of modern tech that makes large organizations hilariously inefficient.

[notarapper]

Jira has many project types and products, and the one most commonly used is actually called Jira SOFTWARE. It literally has software in the name. If you're building a product for software companies, you can think about how to do it better specifically for engineers