将聊天消息移动到新频道导致它们全部混乱

贡献 错误
1

我将 28 条消息从一个频道移到了一个新频道，但它们都乱序了：

JammyDodger
#聊天如何引发话题讨论？

嗯。是我吗，还是这些现在看起来乱序了？:thinking:

JammyDodger
#聊天反馈话题

我又看了一下乱序的帖子，在 https://meta.discourse.org/chat/channel/147/chat?messageId=2644，它们似乎都有相同的时戳。

6 个赞
4

感谢您报告此问题，我尝试在功能中考虑到了这一点，但我认为我测试得太侥幸了 :sweat_smile: 所以我们确实在这里将所有时间戳设置为相同的值：

问题在于我们不希望将移动的消息插入到现有频道消息之间，并且移动的消息越多，这个问题就越难解决。

在我深入研究这个问题之前，我想问一下——您能回忆并确定哪些消息放错位置了吗？只有几条，还是完全乱序了？我认为可能导致这种差异的原因是，当我们按 ID 顺序获取频道消息时（我们通常按 DESC 排序，然后反转）：

而在消息移动器中，我按 created_at 排序以保持顺序，这可能会导致一些小的差异：

我有一些关于如何解决这个问题的想法（也许更改消息移动器以按 ID 排序或更改控制器以按 created_at 排序就足够了，我更倾向于后者，因为它更有意义），但如果可能的话，我想了解一下顺序混乱的程度。

5 个赞
5

我注意到它们在新频道中顺序混乱后，已从原始频道中恢复了删除。我应该能按顺序在这里引用它们：:crossed_fingers:

原始顺序
Originally sent in The Chat Feedback topic
JammyDodger

我正在寻找方法，以捕捉新聊天流程的精髓，以此展示聊天如何成为更宏大讨论的种子。

大家有没有什么想法，关于我们如何基于目前在 Meta 进行的聊天测试来实现这一点？

反馈要点非常棒，我认为它们很快也会独立成正式的话题。但我希望找到一些能作为绝佳范例的内容，供刚加入 @chat-testers 的人参考。让人们一看就能明白：「啊，是的。起初我还不确定，但现在我明白了聊天如何成为深度讨论的前奏」。

我可能要求过高了：slightly_smiling_face:

RGJ

说实话，我不明白聊天如何能成为深度讨论的前奏：thinking:

但这可能是因为我老了。

JammyDodger

所以我们要找的示例，还得能改变 @RGJ 的看法：slightly_smiling_face:

Moin

我喜欢 这里 的例子。但那个例子不太适合这里。也许话题可以关于你目前缺失的某个功能。比如，你因为没时间检查是否有类似的功能请求，或者觉得没人会感兴趣，而没去发起话题的那种情况。

JammyDodger

@Moin，你的搜索能力总是令人赞叹：slightly_smiling_face:

我在找一个关于种子和树木的例子，但没在这里找到。

不过，是的。某种轻松/友好/非正式的聊天，其中某个想法在轻松的来回交流中逐渐成形，随后激发出一个正式的讨论话题。

oshyan

这 100% 符合我对聊天的兴趣和使用场景。但你能具体澄清一下你所说的「例子」指什么吗？你是否感兴趣的是，例如，聊天的样本（无论是否发生在 Discourse 聊天中），这些聊天本应（显然）导致更深入的讨论，或者确实导致了更深入的讨论，但使用的媒介（聊天对比论坛）可能并非最理想？如果是这种情况，我可能需要一点时间去找一些，但我绝对在我的生产力社区中有不错的例子。如果你 specifically 寻找在 Discourse 聊天中的例子，那会难找一些。但我绝对认为这是 Discourse 聊天的一大价值，具体取决于社区，它发挥的作用会有大有小。

Jonathan_Poyer

我认为展示围绕新功能的讨论实际上是一种不错的演示方式，至少在想法的初期阶段。对一些人来说，这种讨论的火花出现在开发期间或即将开始时。总有更多事情可以讨论，引用一个（或多个）话题是有意义的。

oshyan

作为一个可能更概念化的例子，说明聊天何时可以（且应该）迅速转化为话题，即使在讨论中途也是如此：这在我参与的软件开发管理社区以及我的生产力社区中经常发生：

  • 新人加入聊天并提出一个看似简单或无害的问题
  • 来自知识渊博和/或充满激情的常驻用户的回复迅速扩展到数十行文字，开始出现段落换行，该聊天频道变得仅充满关于这一个问题的讨论（话题）
  • 由于每条「消息」包含大量观点和想法，且缺乏选择引用/回复功能，使得解析和回复变得困难
  • 这些对话通常也是有价值的辩论，若不及时处理，会迅速消失在聊天的后续流动中，因此即使事后将它们移入话题，也可能非常有价值
JammyDodger

我想我最初是在寻找一些我们可以在 Meta 上提供的示例话题/聊天，向刚接触 Discourse 聊天的人展示它如何能与 Discourse 既有的「长篇段落」观点很好地融合。

所以，甚至可以是某种我们特意创建出来以清晰展示这一原则的内容。

不过听起来你有很多例子可以成为很好的讨论话题：slightly_smiling_face:

我认为任何能帮助人们轻松可视化聊天在论坛结构中何处切入的内容都会有用。我对所有想法都持开放态度：+1:

agungor

我觉得这场对话本身正在成为这样一个例子。:smiley:

Jonathan_Poyer

感觉在其他平台上，这类内容要么需要变成另一个聊天，要么需要拆分成独立话题。但同时，话题似乎也更像长期讨论，而非像这里的一次性交流？

jimkleiber

也许一种方法是将启动该想法的初始聊天消息引用到一个话题中：How can chat seed topic discussions?

这能让不在聊天中的人看到，尤其是如果话题以问题开头的话。

但讽刺的是，我居然在这里回答 lol

嗯，我刚刚尝试将我的回复引用到同一个话题中，但我觉得我只能引用到新话题，而不能引用到现有话题。

JammyDodger

我刚才也在琢磨这个。:slightly_smiling_face: 我在想是否能为每个人的聊天创建一条回复来组成一个话题，因为没有合适的聊天频道可以容纳它们。但现在你创建了，我意识到它可以拥有自己的聊天频道，我们可以把这场对话移过去 :+1:

jimkleiber

啊，是的，几乎就像是创建一个话题，而这个话题将创建新的聊天频道。

然后这个话题可以填充来自聊天的引用，提炼出亮点。

乱序
Originally sent in How can chat seed topic discussions?
oshyan

这 100% 符合我对聊天的兴趣和使用场景。但你能具体澄清一下你所说的「例子」指什么吗？你是否感兴趣的是，例如，聊天的样本（无论是否发生在 Discourse 聊天中），这些聊天本应（显然）导致更深入的讨论，或者确实导致了更深入的讨论，但使用的媒介（聊天对比论坛）可能并非最理想？如果是这种情况，我可能需要一点时间去找一些，但我绝对在我的生产力社区中有不错的例子。如果你 specifically 寻找在 Discourse 聊天中的例子，那会难找一些。但我绝对认为这是 Discourse 聊天的一大价值，具体取决于社区，它发挥的作用会有大有小。

Jonathan_Poyer

我认为展示围绕新功能的讨论实际上是一种不错的演示方式，至少在想法的初期阶段。对一些人来说，这种讨论的火花出现在开发期间或即将开始时。总有更多事情可以讨论，引用一个（或多个）话题是有意义的。

oshyan

作为一个可能更概念化的例子，说明聊天何时可以（且应该）迅速转化为话题，即使在讨论中途也是如此：这在我参与的软件开发管理社区以及我的生产力社区中经常发生：

  • 新人加入聊天并提出一个看似简单或无害的问题
  • 来自知识渊博和/或充满激情的常驻用户的回复迅速扩展到数十行文字，开始出现段落换行，该聊天频道变得仅充满关于这一个问题的讨论（话题）
  • 由于每条「消息」包含大量观点和想法，且缺乏选择引用/回复功能，使得解析和回复变得困难
  • 这些对话通常也是有价值的辩论，若不及时处理，会迅速消失在聊天的后续流动中，因此即使事后将它们移入话题，也可能非常有价值
JammyDodger

我想我最初是在寻找一些我们可以在 Meta 上提供的示例话题/聊天，向刚接触 Discourse 聊天的人展示它如何能与 Discourse 既有的「长篇段落」观点很好地融合。

所以，甚至可以是某种我们特意创建出来以清晰展示这一原则的内容。

我认为任何能帮助人们轻松可视化聊天在论坛结构中何处切入的内容都会有用。我对所有想法都持开放态度：+1:

我正在寻找方法，以捕捉新聊天流程的精髓，以此展示聊天如何成为更宏大讨论的种子。

不过听起来你有很多例子可以成为很好的讨论话题：slightly_smiling_face:

大家有没有什么想法，关于我们如何基于目前在 Meta 进行的聊天测试来实现这一点？

RGJ

说实话，我不明白聊天如何能成为深度讨论的前奏：thinking:

agungor

我觉得这场对话本身正在成为这样一个例子。:smiley:

Jonathan_Poyer

感觉在其他平台上，这类内容要么需要变成另一个聊天，要么需要拆分成独立话题。但同时，话题似乎也更像长期讨论，而非像这里的一次性交流？

JammyDodger

反馈要点非常棒，我认为它们很快也会独立成正式的话题。但我希望找到一些能作为绝佳范例的内容，供刚加入 @chat-testers 的人参考。让人们一看就能明白：「啊，是的。起初我还不确定，但现在我明白了聊天如何成为深度讨论的前奏」。

jimkleiber

也许一种方法是将启动该想法的初始聊天消息引用到一个话题中：How can chat seed topic discussions?

这能让不在聊天中的人看到，尤其是如果话题以问题开头的话。

JammyDodger

我想，至少是这样。:slightly_smiling_face: 在我采取任何行动之前，我会再确认一下我的想法。

我可能要求过高了：slightly_smiling_face:

jimkleiber

但讽刺的是，我居然在这里回答 lol

RGJ

但这可能是因为我老了。

JammyDodger

我刚才也在琢磨这个。:slightly_smiling_face: 我在想是否能为每个人的聊天创建一条回复来组成一个话题，因为没有合适的聊天频道可以容纳它们。但现在你创建了，我意识到它可以拥有自己的聊天频道，我们可以把这场对话移过去 :+1:

jimkleiber

啊，是的，几乎就像是创建一个话题，而这个话题将创建新的聊天频道。

JammyDodger

所以我们要找的示例，还得能改变 @RGJ 的看法：slightly_smiling_face:

jimkleiber

然后这个话题可以填充来自聊天的引用，提炼出亮点。

Moin

我喜欢 这里 的例子。但那个例子不太适合这里。也许话题可以关于你目前缺失的某个功能。比如，你因为没时间检查是否有类似的功能请求，或者觉得没人会感兴趣，而没去发起话题的那种情况。

JammyDodger

@Moin，你的搜索能力总是令人赞叹：slightly_smiling_face:

我在找一个关于种子和树木的例子，但没在这里找到。

不过，是的。某种轻松/友好/非正式的聊天，其中某个想法在轻松的来回交流中逐渐成形，随后激发出一个正式的讨论话题。

2 个赞
6

我想知道什么时候最好移动消息而不是引用它们。也许这取决于是否已有主题？不确定。在什么情况下，以下哪种方式更适合鼓励人们这样做？

  1. 在现有主题中引用聊天消息
  2. 将聊天消息移动到现有主题
  3. 引用聊天消息到一个新主题
  4. 将聊天消息移动到一个新主题

由于聊天消息串，嗯，比主题更“聊天”，我有点觉得我们可能想鼓励引用而不是移动，总的来说。

有没有人观察到或想到的情况是，你觉得，“不行，在这里引用不好。肯定需要改移动它们。”？

2 个赞
7

如果只引用，讨论可以在两个地方继续。

8

@Moin，您的意思是，当您真的想避免移动消息时，移动消息会更好吗？

9

感谢您完成这项工作——这完全是一团糟！我必须在本地对更大的消息集进行一些测试。我认为至少需要这样做：

不过，我通常对按 ID 排序感到不安，因为存在奇怪的不一致性。我认为按 created_at 对消息进行排序通常对频道更好。@j.jaffeux 或 @mcwumbly，您对此有何看法？如果我们决定这样做，那么消息移动器可能需要为每个值人工添加 10 毫秒或左右的 created_at 间隔，以实现一致排序。

我认为总的来说，如果它们与当前频道完全无关，最好将其移动到更合适的地方。我们以前在内部使用 Mattermost 时多次使用过这个功能。例如，general 频道中的一堆事件响应应该移入 incident 频道，以便更好地进行记录。或者，频道中的闲聊最好移入 random 频道。

我认为在这些情况下引用并留下旧的杂乱内容没有价值，正如 Moin 所说，事情会变得令人困惑，因为讨论在两个不同的地方继续进行。

请记住，这两个选项目前都不存在。我们删除了“移动到主题”，因为在最初的实现中，它为每条聊天消息创建了一个帖子，并且也没有删除频道中的原始消息。如果将来我们想再次实现这个功能，它需要：

  • a) 将消息批量（例如每帖 100 条）使用聊天引用功能进行引用，并且
  • b) 删除频道中的原始消息以避免重复。
5 个赞
10

我将不评论帖子排序的实现，并将由 @j.jaffeux 来评论这方面的内容。

啊，是的。我不是在问在聊天中移动聊天消息，但我可以看到这有多么有用，而且它没有试图在“帖子中”将短格式转换为长格式（或反之亦然）的问题。

有道理。我喜欢引用的通用形式，更像是一个“记录”，因为我认为它很可能会以这种方式阅读。过去，当我使用 Slack 记录功能时，我经常发现自己也将其包装在 [details] 中，并在主帖正文中总结内容。

我在这方面想到的另一个想法是有一个更花哨的“展开上下文”功能，这样你就可以引用一条消息，然后在需要时内联加载其他消息，以便在不离开主题的情况下查看聊天的更多上下文。

我怀疑在引用慢车道/快车道边界之间的讨论时，这部分是否必要或有价值。

4 个赞
11

只有当您选择“移动到主题”时，才会发生这种情况。如果您打算将其移动，为什么还要将消息保留在频道中？我们已经就此进行了内部讨论。当然，将消息正常引用到主题中不会删除任何内容。

给您一些趣闻：生成引用的类实际上称为 ChatTranscriptService :slight_smile:

这很有趣，我们实际上有一个类似的功能，可以引用我们的主题（您可能已经看到了）。在不实际访问频道的情况下，获取更多上下文可能会很有用。

image
image1448×178 19 KB

3 个赞
13

我认为移动的用例是：

  • 我们有一个专门讨论“鲸鱼”的频道
  • 一群人开始就“企鹅”进行深入讨论，因为他们忘记点击“#企鹅”了，事情变得激烈起来
  • 版主介入，然后 :foot: 将企鹅的讨论移到企鹅频道。

我想这里根本的问题是重新排序。

我认为“fudge created_at”是这里唯一合理的解决方案，因为您希望所有内容都作为一个整体被移动？而且它实际上是在移动时创建的。

5 个赞
14

是的，我想知道它是否是必需的，或者是否应该专注于让引用/转录功能真正起作用。

3 个赞
15

是的，如果我们的普通 GET 消息路由是按 created_at 排序的，我百分之百会这样做，这就是我想解决的问题，只是想知道 Joffrey 是否对这方面有一些历史知识。如果没有，将同时更改这两件事。

2 个赞
16

是的，我百分之百支持Sam和你😁 一次性移动所有内容，并将其created_at设置为移动时的时间，我认为是唯一明智的做法。否则，这会打开一个巨大的潘多拉魔盒……我怎么知道在哪里找到它？接收自上次阅读之前创建的内容的未读通知？不行不行不行

4 个赞
17

好的，我将调整移动工具，使移动的消息出现在 :sparkles: 未来 :sparkles: 中，并带有小的间隔增量，然后在 general 控制器中按 created_at 而不是 ID 对聊天消息进行排序 :+1:

3 个赞
21

希望这能解决问题，我刚刚合并了它：

我现在没有做任何事情来人为地将 created_at 延迟到未来，所以我们先看看效果如何。

4 个赞
22

此主题已在 11 天后自动关闭。不再允许回复。