Threaded discussion is ultimately too complex to survive on the public Internet?

似乎有一个新的聊天线程功能。我已阅读大部分内容。这与人们在此处询问的是同一件事吗?

1 个赞

@vel,我不确定。我只想拥有像 Lemmy 和 Reddit 那样的帖子串功能,但该功能的描述充其量是最令人费解的。

1 个赞

首先,我喜欢 Discourse 的讨论格式以及它许多其他精心设计的方面,但对于某些主题,我也非常喜欢它用于深入探讨用户发表的特定评论的线程设计。我希望聊天线程能够解决这个问题,如果还没有的话。

我明白线程存在一些问题,但我认为在某些讨论中它们是合适的,如果有人能够解决这些问题,我认为这里的人们可以弄清楚。具体来说,我认为这是一种组织偏好。您想如何组织这次讨论?

我的主要原因是,有时我想看看谁回复了谁,并且我想回复特定的评论。

2 个赞

有一些相似之处,但线程仅在聊天频道中可用。目前没有计划将线程添加到主题中。

1 个赞

如果是这样,是否可以通过插件添加支持?

1 个赞

使用插件可以实现任何功能,但这将是一项复杂的任务。

需要注意的是,我们刚刚开始现代化主题以移除自定义小部件系统并使用最新版本的 Ember(这可能需要几个月时间),因此现在不是开始这项工作的最佳时机。

4 个赞

这些年来情况已经发生了变化。当有一个好的讨论话题时,线程有助于组织线程式回复。

这篇帖子已经过去 6 年多了。也许全世界的社区在线程方面已经成熟了一些?我想区分一点,社交媒体网站使用的第一层回复排序并不是我感兴趣的。我感兴趣的是能够回复特定评论,并看到这种指示,而不是迷失其中。

我明白有人可能不喜欢线程。为什么?那些具体的原因是什么?请讨论。

附注:我不认为有人要求替代,而是某种可选支持(也许是未来或通过插件)。

1 个赞

Discourse 非常注重版主活动(这对社区整体来说是健康的)。

主题偏离的帖子倾向于被移到另一个或新的主题中。

这就是 Discourse 的方式。

当然,一个插件……

2 个赞

引用似乎在很大程度上可以解决这个问题。另外,如果您点击特定帖子的“回复”按钮,而不是整个主题,您的帖子就会被标记为对该帖子的回复,并且您可以从原始帖子中展开这些回复。

4 个赞

它对我来说一点用都没有,@mpalmer。它确实让我能够弄清楚上下文(而没有该功能,除了纯粹的猜测之外,这是不可能的),但并不能让跟踪特定对话更容易。

2 个赞

这是什么意思?有两种制作插件的方法,而原始方法将被移除?

2 个赞

这意味着代码目前处于变动中,因此在编写插件或主题组件之前,可能值得等到重构后的代码上线生产环境后再进行,以节省您的时间和精力 :slight_smile:

5 个赞

您不能基于先前版本编写插件,然后在需要时进行更新吗?

很明显,@vel,但既然知道更新后需要重写,为什么还要投入精力去做呢?

1 个赞

我认为 Discourse 有允许对话自行串联成新主题的理念,只是它并不方便用户 1) 创建此类链接主题 或 2) 查看链接主题的详细信息。

我可能以前说过,但我认为 Discourse 就像一张大圆桌,每个人都在参与,对话按顺序进行,一个人接一个人。

现在,在现实生活中,大桌子经常会分成几个小对话,我认为人们会称之为串联。也许 Discourse 的类比是,主桌想保持在一个话题上,所以几个人共同决定离开桌子,去另一个桌子或另一个房间(通常是链接主题)。

在现实生活中,有时可以看到人们离开的原因以及他们想谈论的内容、有多少人加入、新讨论的氛围如何等等。

在 Discourse 上,我认为目前在当前讨论中,我们对新讨论的唯一可见信息是带有新主题标题的链接图标列表:

如果能更详细一些呢?显示新主题的类别、标签、回复该主题的人数等?甚至可能区分是有人通过点击主题内的“回复为链接主题”按钮创建的,还是有人在已存在的主题中发布指向当前主题的链接?

现在,我必须提醒自己查看链接主题的链接,老实说,每次点击它们,除了该标题的主题外,我都不知道会得到什么。

所以我想,这可能不是要重建 Discourse 以允许嵌套对话,而是要突出链接主题功能,并从创建的便捷性以及查看其中的内容的便捷性方面对其进行一些调整。

1 个赞

@vel,请立即着手编写此插件,在新代码部署后您可以对其进行更新。您的热情显而易见,我相信您已准备好投入所需的时间。

1 个赞

我相信如果 Discourse 支持多线程(原生或插件)(允许实例所有者选择在有意义的地方使用它),它将拥有更多客户。

我不知道现在处理它是否比以后更费力。我想这取决于。但是,通过处理它的过程,无论你最终实现了什么,你都可以重用那些代码或经验,如果它需要重写的话。通过现在处理某件事,它可能会更好,这样重构就可以包含任何可能需要的 API。

我为工作编写插件(拥有超过 10 年的经验),所以这对我来说没问题。但我没有为 Discourse 编写过插件。如果有人为它筹集了资金,我会编写一个(出于各种原因——我不想开始编写却因财务问题而被迫中断)。或者,如果有人编写的插件具有我想要的功能,我会为他提供帮助。

1 个赞

@vel,

取决于什么?

这取决于在重构 Ember 实现的过程中,有多少以及哪些内容会发生变化。

这句话含糊不清,而且无论如何都有点不合逻辑。


我完全同意。

是的。这取决于此。我不知道有什么变化,以及 Ember 与此有何关系。如果插件 API 保持不变,那么我现在开始或稍后开始都没有关系。如果 API 发生变化,那么如果我现在正在处理它,而他们正在进行重构,那么他们就可以收到关于我需要的 API 的反馈。

如果他们正在用 Ember SDK 重写 Discourse 本身,那么不,我不会花时间在这上面。

1 个赞