类似于……分类组 - 主题组件？虽然想出包含所有内容的分类组并不难，但我们会失去父分类及其子分类的汇总功能。
我在这方面没有遇到困难，但这可能不是很直观。如果默认设置在侧边栏列表中包含父分类，那么将它们全部设置为“在此分类的主题上方显示子分类列表”/“框”（Box），类似于 Documentation，可能会很不错：
（如果我重复了建议，请原谅——这个主题内容太多了。）
3 个赞
别担心。我们都在这里集思广益……
是的，@bryce 在别处也与我分享了一些类似的反馈。我打算看看我们能在这方面做些什么。
我之前将事情概括为两个选项：
但 Bryce 建议可能还有第三种选择——更清楚地区分哪种类型是哪种类型——所以我打算先尝试那个。
请稍候……
2 个赞
好的，我今天在这些方面取得了一些进展：
- 限制在主要用作子类别容器的顶级类别中发帖
- 为新类别添加了描述，以便显示它们的横幅
- 配置了顶级类别以显示其子类别，使它们更容易被发现
我仍然需要处理这个问题：
我会很快回到解决那个问题上。
3 个赞
2 个赞
下面是一个主题列表，但我上面分享的是我滚动之前看到的内容。平板电脑的垂直空间是有限的。
2 个赞
我认为这在旧的 #theme 或 #theme-component 类别的横幅中已经存在了。
3 个赞
我在这里做了一些小的改动，我认为会有帮助：
- 我将“General”（常规）移出了这个类别，作为一个额外的顶级类别
- 我稍微重新排列了类别，所以“Community Building”（社区建设）排在第二位（在“News and Events”（新闻与活动）之后排第一）。
- 我使类别描述更简洁了一些
- 我没有为这个类别添加“显示子类别”
（它也没有在“Support”（支持）中显示）
是否显示子类别的决定取决于是否允许（或鼓励）在该顶级级别发帖 - 我没有移出其他三个子类别（data and reporting（数据与报告），praise（赞扬），comparison（比较））。
目前，这些对我来说仍然是最好的归属地。
现在有 3 个主要的、顶级的讨论类别：
- Community Building（社区建设）
- General（常规）
- Support（支持）
其他的顶级类别更像是“类别组”——主要是子类别的容器。
我想继续塑造这个“Community Building”类别。我想知道是否有方法可以为更多此类讨论提供更大的便利，例如：
- 帮助刚接触 Discourse 的社区管理员了解产品的使用方法
- 帮助刚接触社区管理的工作的网站管理员了解实践的使用方法
- 分享故事/经验
但这可能是在其他事情稍微稳定下来之后，需要更独立关注的事情。
4 个赞
我觉得“General”（通用）在 Meta 上并不是一个非常有用的类别。它目前包含两百多个主题，但查看后发现其中许多主题实际上更适合“Site Feedback”（站点反馈）、“Feature”（功能）或“Support”（支持）。
我认为清理该类别后，可能只剩下大约 50 个确实不属于任何其他类别的帖子。对于这些帖子，一个更具体的类别名称可能会更有意义（例如“Off-topic”（离题）、“Random Talk”（闲聊）、“Watercooler”（水冷却器）等），而不是“General”（通用）。
2 个赞
我还没有真正使用它，但我已经发现了一些问题：
#wiki是可以的，因为它显示了所有的子维基。- 但是子维基“index”链接指向一个分类而不是索引主题（至少在“Developer wiki”的例子中），这需要再点击一次才能访问你可以 \text{Ctrl}+\text{f} 的一次性资源。
- 由于某种原因，“Forum summaries”的描述没有显示在
#news-and-events页面上。 - 我选择在我的分类选项卡中放置
#news-and-events:announcements，但也可以恢复到默认的#news-and-events，因为我对#news-and-events:blog也感兴趣。 #community-building:data-reporting对我来说位置明显不对。#support不显示子分类，这在你想寻求特定帮助时是有害的。- 对我来说，“Data Reporting”属于
#customization。 - 在
#documentation中，索引链接对于#documentation:site-management和#documentation:developer-guides不容易直接访问。你应该使用像#documentation:contributing那样的更短的描述，以便索引链接可以立即点击。然后在分类描述的其余部分使用更详细的描述。 - 文档中的索引链接应该指向索引_主题_，而不是分类（节省一次点击）。
- 在我的分类选项卡中，我放置了所有维基，但我应该定制并指向维基索引主题以节省一次点击。
#dev是一个顶级分类，还是应该是 support 的子分类？那么“solid dev knowledge”应该是文档……我不确定，但这似乎很多#dev主题都是对开发人员的支持。我建议将#dev移到 support 下，默认将其静音，并创建一个专门的开发人员组来取消该分类的静音。
2 个赞
感谢所有反馈，@hellekin —— 以下是对每一条评论的一些回复：
啊，有意思。链接是正确的，但是这些框体阻止了点击。点击框体内的任何位置都会被框体本身捕获，即使链接看起来是可点击的：
这是一个很好的建议，但我认为在解决第一个问题之前，这不会有帮助，否则这些链接根本无法点击。
嗯……“对我来说是有效的”：
您能分享一下您在这里看到的内容的截图吗？
知道了。我仍然需要就 Community Building 开启一个新主题，就像之前承诺的那样。我上周不在，这周也会不在，所以可能要等到下周才能做那件事。
我不认为那是它的正确位置，但我们将在即将到来的主题中更深入地讨论它。
我决定（暂时）_不_在允许在顶级发布内容的父分类中显示子分类。
我们解决这个问题的方式可能取决于我们对主题下一迭代的方向（抄送 @manuel）
我在探索时多次调整了这个分类的位置。首先，我把它放在 Contribute 下面。然后，我把它放在 Customization 下面。最后，我决定它需要成为一个顶级分类。
考虑到参与这些不同类别的可能用户，我认为它应该独立存在。
这只是默认分类框目前的工作方式。我们或许可以更改默认行为。不过我想知道我们在文档分类中的预期体验是什么。看起来添加索引是考虑到了分类横幅，而不是分类框：
同时，索引主题会固定在主题列表的顶部，当索引主题被阅读时它不会自动取消固定。所以我们在这个索引上做了很多重复工作：首先，它旨在生成侧边栏菜单。然后我们将其固定在主题列表的顶部。然后我们在可见的分类描述中添加一个指向它的链接。
我认为我们可以直接删除文档分类中描述里的链接。
1 个赞
嗯……这不是我的经验。
但是是的，如果它对我那样工作，那么我认为我不太需要索引出现在这些描述中。
无论如何，这清楚地表明该链接是我们新的文档插件可用性差距的一个权宜之计。
1 个赞
这很奇怪。我进入了几个分类，话题在所有分类中都保持置顶状态。我们能调试一下这个问题吗？
1 个赞
我正想问一下你们是如何配置自动取消置顶主题的？我记得 Meta 上的默认设置前段时间改了
但看起来这里的“自动取消置顶主题”现在被禁用了；至少我再也找不到这个选项在我的偏好设置里了。
3 个赞
是的，还有两个设置。我认为自动取消置顶主题指的是任何手动置顶的主题。而默认主题自动取消置顶只指的是系统默认置顶的主题，比如欢迎主题和“关于此分类”主题。
我们真的需要区分这两者吗？如果需要，我们是否应该改进描述，使它们的区别更明显？
这并不能解释为什么主题没有为 @mcwumbly 保持置顶状态？您是手动更改了置顶状态吗？
1 个赞
我们可以在关于该主题的讨论中继续吗？
2 个赞
也许他是在自动取消置顶仍然启用时阅读了这些主题。索引主题是在禁用自动取消置顶之前一年多创建的。
3 个赞