在我看来，这是比原始文档插件倒退了一步。
我强烈反对这个观点。它让我们在文档外观方面拥有更多的灵活性。此外，它还使得链接到其他分类下的页面，甚至外部链接成为可能。
1 个赞
但是，有数千份文件，并且经常有新文件被添加，这使得这项工作非常手动。
2 个赞
同意，我不知道我能否用 Discourse 来管理 1000 页的文档。尽管有更专业的文档解决方案，但我能想象自己会这样做。没有 Git 的 1000 页文档似乎也很痛苦 
也许这是一个用例的问题。也许您在使用 Discourse 作为文档的早期阶段就会逐渐适应，但在我的领域（技术/用户文档）中，无论如何都需要手动索引。
我发现维护者可以非常轻松地搜索和查找帖子。
但从用户的角度来看，他们可能不熟悉您的产品或刚接触该主题，他们可能不知道该搜索什么，在这种情况下，结构化（根据我的经验）非常有意义，否则用户就会迷失在文档迷宫中。您可以自己测试一下，想想您认为用户会阅读的、分布在各个标签下的 5 到 10 个随机文档。然后尝试仅通过点击您的网站来查找它们，如果您自己查找时遇到困难，您可以想象一下用户体验会是怎样的。
2 个赞
使用筛选功能可以轻松找到所需内容。假设您正在寻找 Glastar 飞机型号的发动机安装说明。您不确定具体要查找什么，但这些概念很容易搜索和筛选：
在旧的文档中，我放入“库”类别中的任何内容都会自动添加到文档中。无需手动维护单独的索引，而这正是我反对的。
1 个赞
我同意当前的设计并非理想状态。
我们需要灵活性，并为此承担了设计债务。这也是我们仍将 Discourse Doc Categories 视为 experimental 的主要原因。
我们打算将来在此设计和构建更好的东西，但这目前并非优先事项。
5 个赞
我认为问题在于，许多网站采用并广泛实施的原始插件现在已被标记为“生命周期结束”，但并未提供与新插件的实用桥梁。
我刚刚在一个使用新插件的网站上实施了一些 KM，因此这段经历仍然历历在目。为了在文档视图中看到任何内容而必须策划一个索引主题，感觉非常笨拙。相比之下，实施旧插件则非常顺利，前提是存在一个不错的标签分类法。
我理解新的需求促使创建了Discourse 文档类别，但据您自己承认，我们正处于一个不满足当前需求的“实验性”插件和一个生命周期有限的旧插件之间。
7 个赞
我完全同意斯蒂芬的观点。
我想知道为什么这被当作一个全新的插件来处理，而不是对原始插件的演变。软件的革命可以很强大——但当它们迅速而果断时，效果最好。
3 个赞
实际上，我并没有使用 Docs 插件来管理文档——我只需要一个简单的用户界面，能够一次性按多个类别和多个标签过滤主题，而且所有这些都在同一个页面上。
默认的 Discourse 界面需要通过“高级搜索”才能实现，这个功能太隐蔽了，而且包含了很多我不需要的过滤器（比如作者或日期）。我想要的是一个更专注、更直接的体验。
旧的 Docs 插件可以帮助我实现这种多类别、多标签的过滤，但它仍然有一个限制：
当我选择一个父类别时，它只显示直接在该父类别下的主题——它不包含其子类别下的主题。
相比之下，默认的类别视图会显示父类别和子类别下的主题。
这就是为什么我仍然在使用这个插件，尽管它并不理想。
这是我之前关于这个问题的请求：Multi menu select Group tags
再次感谢所有花时间讨论和帮助改进此问题的人——你们的支持和见解深表感激。
2 个赞