<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=597346) </details> <!--IssueSummary end--> ### Release notes > Response threading can be disabled, per namespace. ### Problem to solve Currently, comment threads incorporate the worst of both worlds, insofar as threading is concerned. Specifically, although they are threaded, they are solely threaded one level deep. Consequently, conversations are as easily able to veer off-track as anywhere else, with the same negative consequences as anywhere else, yet these tangents are then hidden when the thread is resolved, causing them to repeat elsewhere. ### User experience goal Reduce conversation fragmentation and duplication. ### Proposal Allow response threading to be disabled, per namespace: - Instance - Group - Repository - Profile ### Further details Were the comment section threaded without a depth limit (like Reddit, Lemmy, and KBin are), this would not be problematic, for duplicate tangents would not affect other conversations. However, that is not what this feature request requests. Instead, I merely want a way to disable threaded responses. I do not want a way to disable responses. Discourse demonstrates that correlating responses, in a flat discussion model, is feasible. However, this would require slight effort to implement, and I would appreciate a flat discussion model, even without any ability to correlate responses. Though, note that this problem already exists, especially within threads. ### Documentation - The name of the feature flag (boolean), for an instance, would need to be documented. - How to disable the feature for subordinate namespaces, via the GitLab interface, would need to be documented. ### Availability & Testing This should not affect availability. ### Available Tier Free. ### Feature Usage Metrics This should be tracked. ### What does success look like, and how can we measure that? When the administrator of a namespace is able to disable response threading, this has been accomplished. ### What is the competitive advantage or differentiation for this feature? GitHub discussions provides no way to disable its GitLab-equivalent response threading. Additionally, Forgejo and GitHub's issues implementations already provide none, which many appreciate. ### Links / references Similar has been discussed elsewhere, notably at [`meta.discourse.org/t/63172/72`](https://meta.discourse.org/t/threaded-discussion-is-ultimately-too-complex-to-survive-on-the-public-internet/63172/72?u=rokejulianlockhart). [^1] [^1]: [`central.owncloud.org/t/65711/8`](https://central.owncloud.org/t/proposal-moving-owncloud-community-discussion-to-github-discussions/65711/8?u=rokejulianlockhart)