到目前为止，我都很享受使用 Discourse 3 的体验，尤其是新增的实时聊天功能。
是否计划允许针对单个消息创建主题帖，就像在 Slack 中的体验一样？
是的，我们正在努力为聊天添加线程功能，但它仍处于规划阶段……我们还没有进展到可以提供“2023 年某个时候”以外的任何细节或时间安排。
14 个赞
我们也不确定我们的第一个“帖子”版本具体会是什么样子 
（或者我们会如何称呼它）。我们中的许多人都非常熟悉其他聊天平台中的帖子是如何工作的，但在我们对使用它们的社区的初步探索中，我们看到该功能被采用的成功程度不一——似乎不同的社区（或社区内的频道）在这里有不同的需求（而且有些可以说最好没有它们）。
@chadwcarlson 我很想听听你到目前为止特别的经历。在过去，你在哪些场景中发现帖子最有帮助？你在 Discourse 聊天中遇到过哪些你觉得帖子会有所帮助的场景？
7 个赞
感谢 @awesomerobot！@mcwumbly 有道理。
目前我们非常依赖 Slack，无论是同时对几个问题/主题进行更深入的讨论，还是在单个线程中保持服务状态的持续更新，线程都能以我喜欢的方式保持条理。
到目前为止，在 Discourse 聊天中，我们一直在尝试复制相同的体验。能够将社区聊天连接到所有内容中的主题和帖子，这无疑是一个巨大的优势。根据我在 Slack 上的经验，我现在很难看到没有线程的聊天不会让新用户难以导航。
我猜想在 Discourse 中使用无线程聊天的部分想法是，在聊天中开始一个对话，然后将其移动到一个主题中，作为一种“线程”。也许这就是我在这方面遇到的困难——我仍然认为在我们的案例中，在创建主题之前可能有一些消息，而线程可能会派上用场。
6 个赞
是的，我过去也看到过这种方式奏效，尤其是在团队规模越来越大，没有其他方法来保持组织的情况下。
是的，“将聊天主题视为‘原型主题’”是我们正在考虑的事情。在此期间，我认为它目前已经运作得相当不错了。它肯定与 Slack 的体验不同，所以 迁移 一个已经习惯了这种体验的社区可能会很困难。但我的看法是这样的：
- 聊天只是更随意。放轻松。不要担心保持太有条理
- 让讨论首先在聊天中发展是可以的，即使它没有主题。习惯它的混乱，没关系。
- 当感觉对话已经达到一个点，值得在一个主题中继续时，创建一个主题。
好的，最后一点，它在 实践 中今天看起来和感觉起来是怎样的？
简单模式是：
- 只需创建一个新主题，也许可以提及“正如我们在 #general::channel 中讨论的那样……”
- 将该主题的链接放回频道“嘿，我在这里创建了一个关于这个的主题：主题链接”
高级模式是：
- 选择聊天对话中的所有消息（按住 Shift 单击以选择一个范围，取消选择其中的无关消息）
- 选择“复制”或“在主题中引用”
- 创建一个带有新摘要的主题，但包含来自聊天的完整文字记录，甚至可能在
[details][/details]中 - 将新主题的链接放回聊天中。
根据我们的经验，这两种方法今天都运作良好。
但我同意，主题提供了一个机会，可以使“高级模式”变得 简单。
9 个赞
很高兴读到这个帖子，@chadwcarlson、@awesomerobot 和 @mcwumbly。谢谢分享。
我也在挠头，想象 Discourse 上线索会是什么样子。
我们计划关闭我们的“免费”Slack，并鼓励大家迁移到我们启用了聊天的 Discourse。我非常喜欢 Discourse 的聊天功能，但有时当我想要在某个线索中回复时，会有点卡顿。我想这是一种习惯，一种需要改掉的习惯。
我用过“Fancy mode”。
效果很棒！
我同意这一点。
我还不确定这在实践中会如何运作，但我想知道一些 AI 魔力是否可以识别何时通过聊天形成了一个帖子，然后建议——仅限于那些为 AI 认为正在形成的帖子做出贡献的人——他们可以将这个帖子变成一个新的帖子。如果有人选择“是的，将此转换为帖子”，它将自动执行“Fancy mode”，然后建议一个要发布的帖子。
4 个赞
我的问题是：用户不转移到新话题。他们继续聊天，我也不怪他们（某种程度上我怪他们 ;)），因为对话本来就在那里，而且仍然在那里。
能够批量选择和删除会有帮助，但我们没有那个删除选项。
所以对我来说，开始一个话题只是一个保存宝贵数据的工具，仅此而已。
1 个赞
这在我们列表中，但不确定何时会排到前面。在此期间，解决方法是创建一个单独的频道（也许具有仅限员工的权限），然后批量“移动”消息到那里。
目前会留下难看的存根删除消息痕迹——这也是我们将来会改进的。
没人知道最终会是什么样子 
我们将首先将其作为一个实验性功能来处理，以便在确定特定方向之前尝试一些我们的想法。
在您执行此操作时，请随时告知我们遇到的任何其他摩擦点！
4 个赞
我也对这个功能感兴趣。
我认为值得注意的是，有时用户可能希望从一个永久频道（例如 Dev）分支出一个话题讨论（例如 #issue-X），并且希望所有这些话题讨论都能像 Discourse 的话题一样被分组、存档和搜索，同时仍然保持实时聊天的动态性。
目前，从聊天转移到话题不仅会将讨论分支到一个孤立的话题（这是我们想要的），还会改变讨论的流程，使其变得更慢。我明白有时我们希望随着讨论的“正式化”而放慢速度，但也许有时我们不希望这样。
如果一些 Jakke 的用户仍然使用聊天，我一点也不惊讶——并不是因为他们没有意识到现在有了一个专门的话题，而是因为他们想保持快速的对话流程。
在我们的社区中，有些用户实际上是从论坛（讨论开始的地方）转移到 Discord，以便使用 Discord 线程实时解决争论。
我计划在我们升级到 3.0 后推动将通信整合到 Discourse 中，并且我对“花哨模式”感到兴奋，但我同时也担心，仍然会存在需要从实时频道分支讨论的情况，而我们唯一的选择将是较慢的话题结构，这可能会将用户推回到 Discord 线程。
我认为这里有一个空白，Discourse 自己对线程的看法可以在这里大放异彩。
一些想法：
- 线程应被定义为一个分支的话题性实时聊天，可以由任何人动态创建，之后可以存档（也许由线程创建者陈述结论）。
- 线程应在其自己的列表中可见，就像话题一样，我们应该能够按线程分支的关联频道/类别/话题进行过滤、分组、排序等。像 Discord/Slack 等工具中竞争性实现的最大的弱点之一是线程的可发现性——Discourse 拥有做得更好的基础。
- 能够从任何消息开始创建线程将是很棒的，不仅可以从实时聊天创建线程，还可以从较慢的话题回复创建线程。例如，如果有人回复了一个话题，而你对他们的回复有一个小的澄清问题，但你又不想让这个问题分散主要话题的注意力，你可以开始一个实时线程，引用他们回复的相关部分。回复甚至可以有多个线程，并且这些线程都可以被任何查看该话题的人看到。这将消除我社区中人们希望离开 Discourse 以更快地解决问题的麻烦。它还将使话题保持更清洁的副产品——因为它们应该被限制在精心制定的论点上，而所有粗略的讨论都将分支到线程中。
- 如果你担心分支讨论会使理解大局变得更加困难，我认为可以通过 1) 人们将分支讨论具体化为更正式的话题回复，2) 人工智能摘要工具来解决这个问题。
编辑补充：
我认为我们正接近一个点，特别是如果核心团队正在试验线程，那么在 UI/UX 中需要澄清话题/回复/聊天/线程的层次结构。
目前它已经有些令人困惑了。我可以回复一个话题，也可以回复一个回复。目前两者在视觉上的唯一区别是，回复一个回复有一个指示器显示我回复了谁。对于其他跟随者来说，可能很难看到话题的讨论是如何分支的。我们可以借鉴 Reddit 的方式，通过嵌套回复来回复回复。基础已经在 Post Voting 插件中。
引入线程，关于层次结构/分支的问题会更深入。
如果我们能够从话题回复创建线程，那么这些线程在视觉上需要与嵌套的回复（假设进行了该更改）区分开来，因为它们在功能上仍然是不同的，线程是实时分支，而回复将是较慢话题结构的嵌套延续。
4 个赞
我们短期内不太可能将话题构建成线程，我们已经多次拒绝了这一点，扁平化的讨论是 Discourse 构建时最早的设计决策之一：Web Discussions: Flat by Design
包含许多子讨论的话题通常很难理解，无论是否嵌套，如果其中有任何重要内容被嵌套，在重复访问时会很难找到。如果一个话题开始向不同的方向分支，通常最好是另开一个新话题。
4 个赞
而这正是关键所在。
Discourse 非常重视版主管理，而这一切都是版主管理流程的一部分。
1 个赞
Sam，那些测试进展得怎么样了？
我知道我们的测试社区会很乐意尝试聊天线程。
2 个赞
我认为我们应该在一周内分享一些东西。我们计划公开功能标志，并创建一个简短的主题，概述该功能，让人们开始试用。
4 个赞