好吧，我肯定需要一些时间来适应新的颜色。Customization > Theme 看起来像旧的 #announcements:blog 类别。
1 个赞
让我感到困惑的一件事是，为什么 Community Building > General 现在在 Community Building 下面了——感觉通用类别成为子类别是错误的。
4 个赞
我这样做了，但大多数我希望直接访问的分类现在都隐藏了。所以我勾选了我想要它们可见的子分类框，并隐藏了一些顶级分类，这样对我来说更实用了。
3 个赞
主题页面顶部的类别过滤器不显示子类别，这是预期的行为。但通常您可以使用搜索来查找它们。这在 Meta 上对我不起作用，可能是因为 #lazy-load-categories。这让我想起了我在这里报告的问题 https://meta.discourse.org/t/search-in-category-drop-down-missing/388911。
这是我在这里看到的情况，没有搜索选项：
这是我所怀念的：
我更希望能够直接访问，例如翻译类别，而无需先访问父类别。
3 个赞
是的，如果我们继续走这条路，颜色选择可能需要仔细看看。
你能分享一些你决定重新添加的子类别的例子吗？
是的，我会继续考虑这个问题……
嗯……你能分享一张这个对你不奏效的截图吗？这是我在那里搜索翻译的截图：
1 个赞
你期望什么样的截图？
我附上了这个：
也许你能看到比我更多的分类。我认为如果分类少于 10 个，就会添加某种限制，从而隐藏搜索功能。
或者因为你为你侧边栏配置的分类，所以加载了更多的分类。我那里只有一个分类（因为不可能为 0，那样我会得到所有默认分类）。
1 个赞
啊，好的，我可以在登出时重现这个问题。谢谢。
我们会看看能做些什么来改善这一点。
我想先适应一下这种新样式，看看我们能学到什么。
您现在可以尝试将主页更改为“最新”吗？
请记住，当我们在这个部分取得进一步进展时，体验的这一部分很可能会发生变化：
1 个赞
我的意思是，我想我现在别无选择，只是对我来说很奇怪，我们正在追求更低的信息密度，因为目前这个页面一点用都没有，真不幸。
我很遗憾地说，我绝对不喜欢#community-building（社区建设）的主题列表现在充满了各种与我之前认为该类别涵盖的“社区管理”领域无关的内容——在数据、赞扬、一般性问题之间，它对我来说变得一团糟，稀释了该类别的价值：
2 个赞
Support > WordPress 类别令人困惑——我最初有一个关于 Discourse 和 WordPress 的一般性问题，所以发在了那里，但它似乎只与插件有关（@Moin，我是否正确理解了您将其移至 Support 的原因？）。感觉这应该是一个 Customization > Plugin 中的主题，而不是一个完整的类别？或者如果它比插件更广泛，应该更新描述？
它不是一个 Discourse 插件。它是一个 WordPress 插件。在 Customization > Extras 中有一些关于它的主题，例如 https://meta.discourse.org/t/wp-discourse-1-5-release/74551，但那不是一个支持问题的分类。
我喜欢它有一个独立的支持分类，而不是仅仅在通用支持分类中使用 wp-discourse 标签，因为它有助于我决定可以在哪里提供帮助，就像 Support > Self-hosting 分开了关于安装和更新的问题一样。
2 个赞
我也不喜欢。
我会考虑下一步尝试进行什么调整。
2 个赞
我仍然认为 Community Building > Data & reporting 中的大部分内容更像是 #sql-help，后者应该是一个支持类别。
引用给所有没有看到我之前说过什么的人
1 个赞
我将避免对这个分类重组发表我的意见，因为它可能值得一试，看看效果如何，但无论如何，我都不喜欢侧边栏上那些彩虹色的分类项目符号。
这很乱。
我的眼睛更喜欢单一颜色的简洁。
另外……我通常不喜欢蓝色/红色的组合，因为我的眼镜有色差。
根据我通过眼镜看的方式，Community Building > Data & reporting 的项目符号看起来会像
或 
或 
是的，就是这样…… 
5 个赞
我相当确定我们这里存在一个关键的权限问题 
https://meta.discourse.org/t/top-mobile-app-development-companies-in-saudi-arabia/397094?u=darkpixlz
2 个赞
同意。顺便说一下，我需要在我的社区中修复同样类型的问题，这就是我之前讨论中指出的缺少某种“类目概览”界面的一个痛点。
参见 How to add multiple tags up front
4 个赞
正如许多人一路上建议或暗示的那样，我认为在很多情况下，我所寻找的更像是“类别组”而不是“父类别”。
我对当前实验感到的一些问题：
- 是否允许在父类别中发帖？
我真的不希望人们在其中一些顶级类别中发帖——例如，“自定义 (Customizations)”。我可以阻止它，但如果对某些类别允许而对另一些不允许，那就有点尴尬了。 - 难以仅过滤到父类别
我将“社区建设 (Community Building)”放在顶层，但如果你只想查看这一个类别，子类别就会显得多余。 - 缺乏对子类别的直接访问
人们想直接访问“错误 (bug)”、“功能 (feature)”或“用户体验 (UX)”等，但将它们嵌套起来使得访问很麻烦，尤其是在主题列表的下拉菜单中。
我正在权衡以下两个选项作为下一步：
- 进一步扭曲结构以实现一致的层级结构
在所有地方禁止在顶级类别中发帖——将所有主题推入子类别。 - 恢复原状，然后重新思考
回到以前的方式。谨慎但有目的地使用父/子类别，并在使用父类别时允许在其中发帖。重新评估下一步。
6 个赞
对我来说，这是最大的问题，也是我在尝试在我自己的社区中构建结构时遇到的最大问题。
如果菜单能以某种方式允许深入到子类别，那可能会奏效：
- 如果您不希望人们在父类别中发帖，请在该类别页面上突出显示子类别框
- 人们有时会使用父类别，但主题可以很容易地移至子类别并进行教育
- 如果在父类别中发帖没有问题，那么就不要用框把子类别推到前面，或者干脆不要显示它们
2 个赞