新的文档插件正在开发中

我们最近发布了新的文档插件供测试和反馈。该插件旨在增强 Discourse 上托管文档的导航和可访问性,为所有用户提供更易于访问和友好的体验。请注意,此插件仍处于开发阶段。

此插件的开发源于我们改进文档的持续努力,该文档已通过新的侧边栏得到增强。侧边栏工作为改进文档体验奠定了基础,新插件在此工作的基础上逐步构建。

:boom: 新插件的实际应用

该插件目前已激活,并为我们的官方 Discourse 文档提供支持。我们邀请您探索其功能并与我们分享您的体验。您的反馈对于帮助我们完善和增强插件至关重要。

新插件包含的核心功能是:

  • 用于定义文档所用类别的设置
  • 由每个类别中的索引主题填充的新文档侧边栏
  • 两个新报告,用于帮助维护索引主题的完整性和准确性

随着我们不断改进可用功能,还有更多功能正在开发中。

新插件现已可供下载和安装:Discourse Doc Categories

:electric_plug: 从 Discourse Docs 插件迁移

随着我们的创新和前进,我们将逐步淘汰旧的Discourse Docs 插件。但是,您可以放心,在新的插件完全准备好广泛发布之前,我们将继续支持它。我们还确保新插件将重定向旧插件的 URL,因此切换不会导致任何链接中断。

请注意,新插件仍处于实验阶段。虽然我们的目标是提供无缝的体验,但可能仍有一些需要进一步改进的领域。您的建设性反馈对其成功至关重要。

:speaking_head: 告诉我们您的想法

我们很想听听您的想法、体验和反馈。无论您是通过浏览 Meta 上的文档,还是在自己的网站上安装该插件,都可以随时分享您的体验以及在使用新文档插件时获得的任何见解。

我们的目标是为整个 Discourse 社区塑造更好的文档体验,因此欢迎所有反馈!

完整的插件详情请参见:

13 个赞

有人需要更新自述文件。也许还可以更新 lint 规则以避免这种情况发生,尽管存在先有鸡还是先有蛋的问题。

看起来它也非常适合将 Discourse 用作 LMS。为此,需要能够切换哪个类别是文档类别,尽管很有可能仅使用权限来授予用户访问特定类别的权限就足以让它正常工作。

8 个赞

URL 抓取得很及时——我刚刚提交了一个 PR 来添加它。

这听起来是一个有趣的用例,我可以看到它如何很好地实现!

6 个赞

这是对原始 Docs/知识库插件的绝佳改进。到目前为止,它看起来非常用户友好。

在 Meta 上进行测试绝对是一个巨大的优势,因为以前在这里的文档类别很难找到东西。

5 个赞

我敢问一下预计到达时间吗?也就是说,这个插件何时才能被认为不那么实验性,而是进入 Beta 版,甚至早期发布候选阶段?我知道预测未来有多难,所以我对任何粗略的估计都会感到满意,无论它多么不准确。 :wink:

我目前正在工作中探索 Discourse 作为一种工具,正是因为它似乎能够很好地结合社区讨论和共享空间用于文档。在这里,编写文档就像在主题上发表评论一样容易。

所以,维基主题功能本身当然很棒,这是一个很好的开始。但是,这个插件为主题内容增加了凝聚力,我认为这对于文档的用户体验至关重要。

meta.discourse.org 上的文档类别现在感觉像一个结构正确的文档站点,而不仅仅是一些碰巧属于同一类别并且碰巧描述 Discourse 如何工作的随机论坛主题。

所以,继续努力。谢谢!

1 个赞

我非常喜欢!文档和讨论非常契合。

您是否计划除类别外,还启用标签的索引?

我认为我们目前所处的阶段是“美(或缺乏美)在于观察者的眼中”。

它之所以是实验性的,是因为存在已知的用户体验问题,特别是对于那些负责维护文档和索引的人来说,但它在生产环境中是完全_安全_的。

也就是说,如果您尝试一下并亲自体验,我们将非常欢迎您的反馈。

目前我们还没有关于改善索引维护方面已知用户体验问题的预计发布时间,但来自使用该插件的用户反馈可能会有助于推动这方面的发展。

不,这并不是我们之前考虑过的事情。您能多分享一些您的想法,或者说明为什么这对您有帮助吗?

4 个赞

关于这一点:如果您在一个文档类别中,然后关闭了一个非全屏聊天窗口,文档导航也会被“关闭”,并且常规的导航栏会再次显示。在 meta 上重现此问题时,我还注意到点击聊天气泡(顶部右侧标题)也会关闭文档导航。希望这有帮助!

3 个赞

感谢您的报告——我能够重现此问题,因此已将其记录下来,我们将在接下来的开发工作中包含此问题。

3 个赞

这让我想起 Discourse 项目的一件事,对我一个用户来说,这并不是很理想。那就是该项目没有使用一个合适的公共问题跟踪器来处理 bug 和规划。

例如,当我读到 Hugh 的回复时,我内部的项目经理立刻提出了一个问题:“在哪里,在哪里记录了这个问题?”。我知道,我的内部项目经理是个爱管闲事的小家伙,不是吗?:slight_smile:

我猜想使用 meta.discourse.org 作为问题跟踪器让该项目有机会“自给自足”地使用 Discourse。而且所有其他的问题跟踪器都有自己的缺点,所以选择一个很麻烦。但对我来说,Discourse——虽然作为提问和讨论的论坛非常出色——但作为一个问题跟踪器却非常欠缺。为此,它缺乏有效的分类、受影响和目标版本信息、问题编号、优先级、按状态、年龄、优先级、产品或组件过滤问题的有效方法,以及展示功能或整个产品的路线图的好方法,等等。

好了,我离题了。而且我还没有贡献一行代码、一个 bug 报告或一个功能请求,我有什么资格抱怨呢。 :wink:

所以,再次感谢大家带来的出色的 Discourse。并请原谅我这半吊子的抱怨。

回到正题,很高兴听到 Discourse 文档分类虽然还没有打磨好,但被认为是架构稳定的。我会看看是否能在我的托管 Discourse 实例上安装它,如果可以的话,我会带着反馈回来。谢谢!

6 个赞

我忘记在这里回答了。感谢您的跟进。

我知道 #wiki 可以归入诸如 community support dev 等不同类别,并且根据用户的兴趣主题展示数据会更好。

同时,在文档(wiki 侧边栏链接)中展示这些已组织的 wiki 听起来很棒。

1 个赞

我们使用 Discourse 作为 issue tracker。更确切地说——我试图强迫我的团队使用 Discourse 作为 issue tracker :slight_smile: 还有 wiki、论坛和文档……我怀疑 CDCK 团队有另一个“秘密”的 Discourse 站点,他们在那里使用一些有趣的插件来跟踪他们的东西,没有人……

无论这里的 issue tracker 多么好,社区都无法与我所知的任何其他东西相比。归根结底是人开发软件,而不是它背后的技术。他们太棒了!:metal:

而且我非常喜欢文档插件。:heart:

现在,在我所有的赞美之后,能否批准我的 PR:smiley:

5 个赞

你看到 Gerhard 在那个 PR 上的回复了吗?

3 个赞

我们确实有另一个供内部使用的站点,我们确实通过它来跟踪我们的许多工作。但我们并没有使用任何秘密插件。

主要是,我们使用约定,例如一个用于“待办事项”的类别,以及一套标准的几个标签用于某种“现在/下一步/稍后”的优先级排序,以及 assign 插件来明确所有权。

这也能让看板主题组件工作,但并非所有人都使用该视图。

它相当灵活,不是一个高度主观的议题跟踪器,但对我们来说效果很好。

我有时可以分享更多细节……

6 个赞

没有!是我的错。已修复。感谢通知。

3 个赞