我不这么认为
很可能如此，但如果是那样，那也是很久以前发生的事情，我记不太清了。
但这似乎是最合理的解释。
1 个赞
也许你更改了对 News and Events > Forum summaries 的跟踪设置？它默认是静音的，而且看起来静音类别的描述不会显示 
3 个赞
啊，确实，它被静音了。@Moin 你观察得很敏锐。我想那它可以变成灰色，这样看起来就不会奇怪了。
3 个赞
[quote=“Moin, 帖子：68，主题：396306”]
看起来静音的分类不会显示描述。[/quote]
这似乎很奇怪。会有理由显示分类却不显示其描述吗？还是这很可能是一个疏忽？
在使用新的分类体系一段时间后，我必须说，我并不喜欢它。新的组织方式并没有让我特别烦恼，但我还是更喜欢旧的方式。
在阅读了 Do users properly use categories? - #6 by Bas 和 Do users properly use categories? - #9 by noahl Discourse 论坛多年之后，我仍然认为更少的分类可能更有益，也更不容易让人困惑。
我更喜欢那些没有（或只有少量）子分类的组织方式。
当我们创建新主题时，这并不会真的造成什么摩擦，但我觉得很奇怪：我们可以在某些父分类（例如 Support）中创建主题，而在其他分类（例如 Contribute）中却必须使用子分类。
在帖子中链接分类或在搜索时自动补全分类，可能会生成非常长的字符串：
Community Building > Data & reporting, Documentation > Migrating to Discourse, News and Events > Forum summaries 等等。
特别是在移动设备上创建新主题时，基本上无法显示完整的分类路径。甚至连父分类也会被截断：
当然，新的组织方式并不是这里唯一的問題（参见 Creating/Editing a post on mobile: let's discuss the 2026 Discourse experience
我在搜索页面上特意使用了一个非常长的分类，但我甚至看不到我正在寻找的关键词，因为分类字符串占用了所有空间。
总的来说，我觉得像 #category:sub-category 这样的长字符串很难阅读。
而且在“分类”侧边栏部分：
我们有表情符号、图标和双色项目符号，这让我非常想起那些口香糖：
可能这里还有一些正在进行的工作，特别是关于只使用图标而不再使用表情符号，但即便如此，图标和双色项目符号的混合（有时看起来像单一颜色，例如 Contribute > Feature）仍然显得杂乱。
我理解当各个事项被归类到各自专属的空间时，这样确实更便于搜索精确信息。
我赞赏大家为改善用户和管理员体验而进行的协作努力，但到目前为止，我并未被这些最近的更改所说服。
5 个赞
有一件事让我觉得有点 frustrating，就是我现在无法再输入 #contribute:bug 来链接到 Contribute > Bug 了。那里的父类别阻碍了这一操作。
我通常不使用自动补全弹出窗口，更喜欢手动输入所有内容（更不用说自动补全需要几秒钟才能显示出来），所以在 Bug/UX/Feature 作为父类别的情况下，我必须先回想父类别的名称，然后再输入它。
5 个赞
我几乎总是找不到任何东西，最终不得不去 ask.discourse.org 查找几乎所有问题，包括如何配置某个插件或找到我知道存在的文档。有时候直接用 Google 搜索可能更明智。
想找 LDAP 插件？搜索“ldap Customization > Plugin”却找不到它。它到底在哪里？是 #self-hosting/discourse-ldap-auth 吗？——Google 却能找到。它实际上位于 Support > Self-hosting 分类下，并带有 discourse-ldap-auth 标签。所以你必须猜测某个插件是否属于 Customization > Plugin？什么时候插件不算插件了？
说真的，每次我需要查找东西时，我最终都直接去 ask.discourse.org。
我不确定我是否太在意把新帖子放在哪个分类里。我通常把一切都放在 Support 中，除非我觉得它与管理有关，那时我会尝试把它放在 Support > Self-hosting 中？
2 个赞
关于此问题的这个开放型用户体验请求或许可以再次提上日程：
能否让子类别的内联链接更简洁？ - 贡献 / 用户体验
3 个赞