我们拥有大量的指南，有时 @dax 或 @jomaxro 会分享一些我都不知道存在的 howto 指南，让我大开眼界！
我也发现，Discourse 这里的许多新用户和社区管理员在 Meta 上也常有同样的情况。为了解决这个问题，@justin 想出了一个绝妙的主意：将我们的操作指南归类，为每个人提供更好的入门起点，希望能最终打造出类似 https://support.teams.discourse.com/docs 的内容。
目前我考虑分为以下三个类别：
你认为哪些 howto 应该归入哪个类别呢？
非常期待听到大家的想法 
我觉得这里不会收到任何回复，因为大家没有动力来做这项工作。
我们要么将其分配给我们的团队，要么需要找到一种简化的方法（比如使用标签？）。
内容太多了：sweat_smile:
看来我错了！谢谢。
哈哈，确实如此！理想情况下，如果每个分类能有 6 到 12 篇操作指南就太好了。我们并非要归类所有内容，只需精选大家最可能查找的那些。
@osioke —— 一种可行的方法是，找出与这些分类相关且浏览量最高的操作指南，然后挑选浏览量排名前 6 到 12 的进行相应标记。这将是一个轻松的起点，再结合 @Benjamin_D 在此处提出的建议！
标签的好处在于，我们也可以在过程中随时轻松编辑它们。
感谢分享，@Benjamin_D！我之前一直在纠结如何呈现内容以及如何构思结构，你这里的表格帮了大忙。
我现在正计划将分组从 3 个扩展到 6 个：
就像 @justin 分享的那样，我查看了浏览量最高的帖子，以下是前 20 个：
大家觉得怎么样？
这将是一个较大的改动，所以请允许我请出“重武器”，并抄送 @trust_level_3。
嗯，登录设置相关的文章或许可以单独设立一个分类。它属于“入门指南”的一部分，因为如果你打算在新网站上进行配置，这通常是首先要做的事情之一。
我不确定这里是否需要提及多站点设置🤔，或者也许高级配置组可以附带一个警告，搜索元数据！例如，这篇帖子非常有用：多站点安装的优缺点。
关于批量发送用户邀请，我现在更倾向于使用可重复使用的邀请链接，或许可以同时提及这两个主题？
我认为我会将设置通过电子邮件回复支持 
放在高级设置组中（因为我还没做过这件事🙈），而简单直接的入站邮件直送也值得提及，但也许放在高级配置组中，因为……嗯……电子邮件太让人抓狂了😱。
贡献组看起来有点空，或许可以添加一些与主题或组件相关的内容，例如：Discourse 主题开发者指南、Discourse 主题设计师指南 和使用主题创建器和主题 CLI 开始构建 Discourse 主题的初学者指南。
确实，这份列表是基于浏览量最高的前20个主题整理的，我分享它是为了说明我在排列思路上的考虑。这绝不是最终版本，我本应表达得更清楚些：
我希望将“管理”或“运维”作为一个类别，用于持续的管理和 Moderation 活动。它既不属于“安装/配置”，也不属于“开发/文档（贡献）”。
我假设 Discourse for Teams 文档站是使用 Discourse 来托管所有文档的。对于 Discourse 的“操作指南”类站点，且允许社区成员参与，这样做的问题在于版本控制和内容追踪。我相信使用 Discourse 作为方案是首选，但我建议可以考虑使用 Hugo 站点 或 Jekyll 站点，将文档作为 GitHub 中的文件存储，任何人都可以提交拉取请求（PR）。如果您不喜欢这两种方案，还有许多其他基于 GitHub 仓库的文档系统可供选择，形式多种多样。
仅供参考，我一直在逐步清理 #howto:sysadmin 中的内容，确保每篇指南都是最新且相关的，然后将它们移至 auto-delete-posts-after 进行处理。看起来其中大多数已被归类为“高级配置”。
完全同意。多站点是一项超级超高级的配置，我们在 Meta 平台上并不太支持它。
确实如此。Discourse + Docs 插件 + 一些额外的自定义。使用 Discourse 是我们的首选方案，但我也看到使用维基或静态站点生成器（SSG）网站也有其优势。
非常感谢你为此付出的努力❤️
如果那些“支持较少”的话题能够被归入一个标记清晰的独立分类，那就太好了。
目前似乎存在一种观念：只要内容写在这里，就理应获得某种程度的支持。
此外，这也更容易倡导用户在升级前进行测试，因为这类功能通常更为脆弱，或在版本发布间经过的测试范围较窄。
子文件夹、多站点、三级分类等都应该归入此类，对吧？
我认为多站点在很大程度上是“受支持”的，但如果你选择这条路，就意味着你需要承担更多的责任（例如，你需要考虑 rebuild app 在不同上下文中的含义）。我会说它属于“高级”范畴，但算不上“超级高级”。
同意你的看法，三级分类和子文件夹确实属于“超级高级”范畴。
也许我更多考虑的是使用 Let’s Encrypt 的多站点方案，该方案多年来曾多次出现故障，而更新的文档有时需要数周甚至数月才会发布。
啊，是的。我认为这现在应该相当稳定了（我记得上一次变更与 nginx 如何处理重定向有关），而且我确实写了一篇关于 Multisite Configuration with Let's Encrypt and no reverse proxy - Documentation - Literate Computing Support 的文章，打算“很快”就发到这里（我撰写并最后测试它的时间是 2020 年 12 月 2 日）。不过，多站点配置基本上得靠自己摸索了。我认为除非你至少有 3 个（也许是 10 个？）站点，否则这样做甚至没有意义，因为大多数认为自己需要多站点的人，似乎只是试图在一台 1GB 内存的 Droplet 上勉强运行。
我认为最有用的做法是：不要过多地调整类别（如“操作指南”）的结构，而是为文档提供更好的结构。
我非常赞同论坛保持流畅，方便用户发帖。为此，关键在于设置好顶层类别，让用户能将其帖子发布到正确的类别中。但当子类别变得复杂，以至于用户必须准确选择子类别发帖，或需要知道在哪个子类别中查找内容时，我觉得这反而会造成一定的干扰。
目前，你们的文档几乎是论坛设置的直接镜像：
为何不利用仅限工作人员的标签来整理和构建文档呢？例如使用 ‘docs-getting-started’、‘docs-setup’ 等标签，并整合来自论坛各处的内容？这样，你们就可以建立一个不仅仅是论坛镜像的文档页面，而是拥有一个经过精心策划的目录，例如：
文档
这确实是我们目前的构想，@manuel！我们计划创建一些方法来轻松按这些类型的操作指南进行筛选，同时保留文档插件中已有的筛选功能。将这些操作指南组织成特定的标签是首要步骤。
