[IshKebab]

That version of JIRA could still easily be configured to be awful. That's the main problem with JIRA - the power to actually configure it to be sane is always reserved by a few people who don't want to bother, don't have time and don't care because they aren't really using it every day.

Well one of the problems anyway. It's also unimaginably slow, and has weird limitations like issues can't be parents of other issues.

[zelphirkalt]

The non-existence or non-availability of recursive features, like an issue being parent of an issue, or in Slack a thread being started inside a thread and so on, to me usually indicates, that the developers of the tool are afraid of recursion, and have never learned how to implement this easily in a database, used a programming language that easily deals with recursion, and don't know how to deal with it in other languages. They tend to think "it's too complicated". It's usually just a silly lazy excuse, but here we are, with tons of inflexible shitty tools.

[auxiliarymoose]

Alternatively, it is a conscious decision to help prevent users from causing complicated situations.

Given a highly configurable system, users will find ways to (unintentionally) tie it into knots, so adding some guardrails can help reduce complexity demons down the line (both in the technical implementation and the user experience).

I guess I prefer to give people making things the benefit of the doubt.

[IshKebab]

> Alternatively, it is a conscious decision to help prevent users from causing complicated situations.

Based on the rest of Jira, it's definitely not that!

[kzalesak]

For Jira, recursion would make sense, for Slack, it depends. For our team of about 30 people, the lack of recursion in threads has been mostly positive.

I guess that the ability to toggle recursion on or off might be helpful.