我先说一下，对于任何使用聊天式沟通的人来说，这有点显而易见——聊天是高度主观的，如果你只选择一个选项，那么找到“正确”的解决方案几乎是不可能的。
我倾向于将聊天线程分为两类：子空间和内联。
遵循子空间格式的平台会在有人回复消息时创建“口袋”，所有回复都保存在这个口袋里，除非有人点击进入，否则是看不到的。人们通常从 Slack 中熟悉这种方式，这也是我如何归类 Discourse 的聊天功能内置的解决方案。
内联回复将所有响应保留在主聊天线程中，并通过链接/锚点指向前文。对此有两种变体——带或不带引用的文本。带引用文本的例子是 Discord（它使用摘录而不是完整的引用）或 Apple 设备上的 Messages。Discord 在切换到当前格式之前曾有过无引用的内联回复。无引用内联回复的另一个例子是 Stack Exchange / Stack Overflow 上的聊天功能。
两者都是有效的，它们都有各自的用途，并且它们各自“解决”了对方造成的问题。
- 我发现子空间口袋……
- + 可以很好地包含一个横向的思路，或者允许深入探讨一个话题，而不会分散主要讨论的注意力。
- + 使这些支线保持整洁且易于遵循，但
- - 口袋很容易被错过，特别是当回复是在聊天已经转向其他话题很久之后创建的。
- - 更重要的是确保你通知了任何需要看到分支的人。
- 内联聊天则相反……
- - 因为一切都是内联的，所以很容易因为跑题而破坏聊天。
- - 同时跟踪多个讨论线可能会令人困惑。
- + 因为一切都是内联的，所以你不会错过子空间里发生的任何事情。
- + 用户不必费心去确保回复能通知到特定的人。
作为多年的 Slack 和 Discord 用户，我认为“正确”的解决方案可能是没有开发者想听到的——两者都要有。我发现对我来说，最大的决定因素是：
- 参与聊天的人数或活跃度如何。
- 如果我只和一个人聊天，或者活动不多，我想要的只是内联回复。即使有 2-3 个人，我也不需要子空间。我无法告诉你多少次我因为 Slack 的私信在两个人之间使用子空间而感到恼火。
- 如果我身处一个有很多参与者并且消息快速发送的空间，那么跟踪内联对话会变得更加困难，特别是当人们随意使用回复功能时。
- 我想/需要看到多少东西。
- 如果我在 Slack 频道中扮演支持角色，子空间可以使频道变得整洁，让我可以快速浏览。
- 如果我身处一个错过埋在线程中的任何内容都会很糟糕的空间，我更喜欢内联回复。害怕错过（FOMO）是真实的，朋友们！
- 线程的“深度”有多深。
- 倾向于在一个问题后有几十甚至上百个回复的频道应该使用子空间。
- 倾向于每个消息只有很少回复的频道通常内联效果更好。
- 我是谁/我习惯了什么。
- 我认识一个人，他创建了一个 Slack 脚本来删除子空间，因为他非常不喜欢它们。
- 我认识一些人，他们坚决要求他们的团队在 Slack 频道中每次都使用子空间线程，并且在没有使用时会有点生气。
这一切都说明，没有一种万能的（甚至是最适合大多数情况的）解决方案。我特意去寻找这个元帖子，因为我在另一个 Discourse 实例上进行了一对一聊天，并惊讶地看到了线程的选择，我真希望我能避免使用线程。
如果您想考虑提供这两种选项，这里有一些想法：
- 考虑一个用户设置，允许用户全局或按聊天选择他们偏好的样式。
- 考虑聊天空间的参与用户数量、消息频率和平均回复深度，以“自动”确定使用哪种形式——例如，使用内联，直到链中的回复达到某个数字，或者用户指示“将回复转换为线程”。
- 考虑“我正在创建对昨天/上周某事的新的回复线程”的情况，以及是否应该指示回复（或允许响应者像 Slack 那样内联发布回复）。
我认为你们现在拥有的已经很好了，但我很希望看到 Discourse 在这个功能的发展过程中考虑模糊这两种不同方法之间的界限。