mcwumbly
2026 年2 月 17 日 17:03
1
作为更新 Meta 主题和结构 的一部分，我们计划对这里的分类组织进行一些更改。
到目前为止，我们已经探索了几种不同的想法，并且我们预计在获得社区反馈后，这仍将经过一些额外的修订，但我们目前倾向的想法如下所示：
基本思想是将相关的分类分组到更少的一级分类中，其中每个分类默认对新用户在侧边栏中可见。
新闻和活动 (News and Events)
支持 (Support)
社区成功 (Community Success)
贡献 (Contribute)
定制 (Customization)
文档 (Documentation)
社区维基 (Community wiki)
市场 (Marketplace)
我们预计“支持”将继续是最活跃的分类之一，并认为将其他与支持相关的分类置于其下可以减少选择的困扰。这里可能还有更多值得改进的地方（SSO 应该是一个分类还是一个标签？安装和托管在实践中有何不同？它们是否应该折叠成一个“自托管”子分类？）我们将逐步解决这些问题，但总体方向是将所有支持主题集中在一个地方。
“社区成功”是我们希望投入更多精力的一个分类，它建立在现有的“社区”分类之上。我们认为这是一个让所有参与运营成功 Discourse 社区的人可以互相支持的地方，不是提供技术支持，而是关于建立成功社区所需的那些棘手的软性问题。我们可能会在这里重塑底层结构，但作为开始，我们认为现有的“社区”和“数据与报告”分类是这里的主要支柱。
“贡献”是我们设想的关于如何改进产品本身和这个社区的讨论中心。
“定制”将是查找所有与使用插件、主题、组件和其他扩展来扩展 Discourse 相关主题的地方。
如果您想仔细了解，我们目前在暂存站点上设置了这个结构，您可以在那里查看。
如何访问暂存站点
访问 https://meta-redesign-2026.discourse.group/
输入此用户名和密码进行 HTTP 基本身份验证
用户名: meta2026bsbx
密码: Q0U1ppbVbd2MVttuYOl+M8SYEOUqGLGjzl5sr1C9XwE=
输入您的电子邮件/用户名和 Meta 密码
在您有机会这样做之后，请在这里告诉我们您的想法。
5 个赞
pfaffman
2026 年2 月 17 日 19:13
2
我认为有一个名为“自托管”（self-hosting）之类的类别可能会有助于明确什么内容应该放在那里。它仍然不是一个很好的名称，但比“安装”（installation）要好，后者暗示着 Discourse 从未正常工作过；我第一次看到我的主题被移到那里时感到非常困惑。也许“后端”（back-end）可以？
如果你访问 shell 来引起或目睹你的问题，它就应该放在那里。如果 Discourse “工作正常”，而问题与用户体验（UX）或主题或任何其他内容有关，则应放在支持（support）中。
7 个赞
mcwumbly
2026 年2 月 17 日 20:15
3
我赞成。
我更进一步说，我们应该将 Installation Installation > Hosting
我认为无论其余部分如何发展，我们都可以做到这一点。如果我们朝着我上面概述的方向发展，这个新类别将是“支持”的一个子类别。
如果我们更贴近当前的扁平模型，它将是一个顶级类别。
4 个赞
mcwumbly
2026 年2 月 18 日 14:52
4
我刚刚进行了以下更改，创建了一个新的顶级分类 Self-hosting support
将先前在 Installation > Hosting 中的所有主题标记为 hosting
将 Installation > Hosting 中的所有主题合并到以前的 Installation
将 Installation 重命名为 Self-hosting support
也许用“Self-hosting”（自托管）比“Self-hosting support”（自托管支持）更好（特别是如果我们将其移到 Support 下面），但作为第一步，我选择了一个稍微冗长一些、包含“support”一词的名称。
3 个赞
就我个人而言，我之前避开了“自托管支持”，因为它给人的印象是那是专门供自托管用户获取所有支持的区域，而我不想让这成为第一印象。
它也与文档类别非常相似，如果你想简化，你真的不希望出现重复。
配置也被否决了，因为所有功能/设置/插件等都需要“配置”，所以它不够具描述性。系统管理员（Sys-admin）被认为技术性太强（因为我们想淡化运行 Discourse 站点需要具备的技术水平）。
尽管我同意“安装”这个名称有些模糊，但它在实践中并没有引起太大的困惑。不过，肯定有更好的名称……
至于“托管”（Hosting），那是讨论底层服务（Digital Ocean、Mailgun 等等）的区域。我认为它确实有一种不同于服务器管理的独特意味，而且如果它有超过 500 个主题，那么将其拆分出来进行讨论是可行的（如果它还没有存在的话
8 个赞
stephtara
2026 年2 月 18 日 15:51
6
对我来说，我期望的是：
托管 (hosting)：关于选择和管理主机（服务器）
安装 (Installation)：达到“Discourse 已经存在，我可以以管理员身份登录并进行操作”的状态
配置 (configuration)：所有关于各种设置的细节
我认为对于初学者来说，核心 (core) 和“捆绑插件 (plugin bundled in)”之间的区别不是很明显。所以我会将它们包含在配置中——或者至少提供非常明确的指向。
3 个赞
mcwumbly
2026 年2 月 18 日 17:20
7
stephtara:
对我来说，我会这样期望：
托管 (hosting)：关于选择和管理主机（服务器）
安装 (Installation)：达到“Discourse 已经存在，我可以以管理员身份登录并进行操作”的状态
配置 (configuration)：所有关于各种设置的细节
您期望这些是不同的分类 (categories) 还是不同的标签 (tags)？
以及您期望它们与 Support
2 个赞
stephtara
2026 年2 月 18 日 18:53
8
所以，我想安装和托管作为标签是可以接受的。但我（以及我的社区）想知道是否有办法将某些关键标签“置顶”或“推介”到一个分类中。如果我们要从“讲述故事”的角度来考虑，它们也可以是分类。
配置：这对于自托管用户还是托管管理员来说会有很大不同？我的印象是它们会有重叠，所以我不确定是否应该将其锁定在“自托管”（我更倾向于重命名而不是“自托管 支持 ”）中。也许 Support
顺便说一句：Migration
我们最近讨论过 facebook-migration Migration
2 个赞
mcwumbly
2026 年2 月 18 日 19:08
9
在应用中对此提供更大的便利性是值得探索的，但我不太确定它应该如何运作。
目前，我认为这种情况是自然发生的——某个分类中积累了大量的特定标签，人们开始看到这种模式并鼓励其蓬勃发展。
有内置功能可以限制某些分类只能使用特定标签，或者要求在特定分类中使用一定数量的标签，特别是来自特定标签组的标签，但我感觉这些功能往往过于繁琐。
是的，我最初也是这么想的……我让它放一天，但明天会重新审视这个细节。
确实如此，但我不太确定多出来的这个词有多大帮助。不过我明白你的意思。
是的，这里面可能隐藏着两个分类。如果我们从提议的嵌套结构的视角来看待这个问题，也许应该将其拆分为更像 support/migration 和更像 dev/migration 的内容。
我可以看到我们随着时间的推移会进一步塑造它，同时先在这里迈出一小步。
stephtara
2026 年2 月 18 日 20:17
10
我明白你的意思——尽管它们隐藏在下拉菜单中，这使得它们的可见性远低于可以突出显示显示的子类别。
我稍后会回复你关于这一点，因为这是我计划广泛使用的一件事
mcwumbly:
我认为配置更多的是“一般支持”
我认为其中一部分是，但另一部分是“安装”的延续，所有的设置工作。是的，我现在安装了 Discourse，它具有所有这些非常酷的功能，我可以控制很多事情，但我如何根据我社区的需求来“塑造”它？这部分曾让我非常气馁，因为尽管所有的设置和内容都有文档记录，但我很难 a) 了解从哪里开始，以及 b) 了解如何将我对社区的“愿景”转化为设置和配置。
所以，我想的是围绕初始 配置过程的额外一层。我认为 Support
说了这么多，我实际上认为“配置”作为管理员旅程的一部分是有意义的，而且它不完全等同于“支持”。
与我的社区进行类比——提醒我需要在适当的对话中提供有关该社区的新消息——如下所示：考虑到一位刚被诊断出患有糖尿病的猫的主人加入了我们的社区，我们如何组织类别？我现在决定的方式是“以会员为中心”，从“我刚到，这是什么鬼”（一些更礼貌的法语等价词）开始，然后是“我正在获取我需要的装备”，“我正在学习”——然后他们才准备好接受社区核心的真正“支持”。
如果我像这样考虑 Discourse，作为一个像我一样对所有事情都完全陌生的人，肯定有：1) 弄清楚我是要自己托管还是不托管，以及选择我的托管方式；2) 完成实际的安装 3) 设计我的社区并将其转化为 Discourse 配置。在这种情况下，需要区分 a) 我是从头开始构建，还是 b) 社区已经存在，我想迁移它——正如我在我的Facebook 迁移挑战 主题中所讨论的，我真的认为这改变了设置东西的方法。
这就引出了将迁移内容放在哪里。
我还是会说，这取决于我们想讲述什么样的故事。Discourse 是想鼓励和促进现有社区迁移到 Discourse，还是更侧重于那些将从头开始使用 Discourse 构建的人？
毫不奇怪，我认为关注迁移客户是有意义的，因为我确信那里有巨大的未开发市场。
在这种情况下，我希望“迁移”不要埋得太深。我个人会将其作为社区管理的一个方面（并重命名当前的社区类别，因为“社区”一词本身是模棱两可的，我最初以为它是“为 Discourse 社区”而不是“关于设计/构建/管理社区”）。标签还是子类别？可能至少应该有一个子类别。围绕迁移的脚本和技术内容是否应该放在另一个顶级类别中？
或者也许迁移本身就是一个类别，其中包含有关如何调整和转换社区现有方面到 Discourse 的讨论，如何处理实际的迁移过程（实施），以及“数据迁移”。
1 个赞
pfaffman
2026 年2 月 18 日 20:32
11
等等。如果我们能像使用 unsupported-install #standard-install 标记主题，会怎么样呢？
不过，我不太确定如何实现这一点。
2 个赞
mcwumbly
2026 年2 月 18 日 21:00
12
在目前的提案中，我们设想“社区成功”是顶级类别，而“社区管理”是其子类别——这与你的想法一致吗？
mcwumbly:
我确实喜欢围绕我们对典型流程步骤的理解来定义一些指引的想法……
1 个赞
stephtara
2026 年2 月 18 日 21:24
13
我不明白这两者之间的区别。社区成功中会有什么内容而社区管理中没有呢？如果我考虑一下我到目前为止在 Community
我得明天或后天再仔细想想了，我今天脑子要罢工了，抱歉！
1 个赞
mcwumbly
2026 年2 月 18 日 22:05
14
stephtara:
社区成功中包含而社区管理中不包含的内容是什么？
好吧，除了模型中看到的那些子类别之外，您在这里提到了除管理 社区（设计和构建它们）之外的另外两项活动：
stephtara:
与其说是“关于设计/构建/管理社区”
但也许对大多数人来说，这仍然都属于“管理”范畴。
mcwumbly:
如何访问预发布站点
点击前往
一键预发布站点（含凭证）
→ 以防机器人访问，此处隐藏。
以下是我对分类的重新调整：
新闻与活动 (News & Events)
公告 (Announcements)
博客 (Blog)
摘要 (Summaries)
社区 (Community)
论坛 (Agora) (原：general)
站点反馈 (Site Feedback)
赞扬 (Praise)
对比 (Comparison)
社区管理 (Community Management)
市场 (Marketplace)
用户维基 (User Wiki)
管理员维基 (Admin Wiki)
开发维基 (Dev Wiki)
系统管理员维基 (Sysadmin Wiki)
文档 (Documentation)
使用 Discourse (Using Discourse)
站点管理 (Site Management)
集成 (Integrations)
Discourse 托管 (Discourse Hosting) (原：Hosted Customers)
自托管 (Self-Hosting)
迁移到 Discourse (Migrating to Discourse)
开发者指南 (Developer Guides)
贡献 (Contributing)
帮助 (Help)
安装 (Installation)
托管 (Hosting)
迁移 (Migration)
集成 (Integrate)
贡献 (Contribute)
错误 (Bug)
功能 (Feature)
开发 (Dev)
翻译 (Translations)
用户体验 (UX)
定制 (Customize)
插件 (Plugin)
附加组件 (Extras)
主题 (Theme)
主题组件 (Theme Component)
数据与报告 (Data & Reporting)
基本原理：
Community #agora ）、站点反馈、赞扬以及与其他软件的比较，同时也包括关于社区管理和市场（marketplace）的讨论。#news-events 将用于 CDCK 的常规沟通。#help 将用于获取支持。#integrate 将用于讨论特定的集成。Documentation #contribute 将托管所有开发过程。#customize 将托管使每个 Discourse 实例成为特殊社区的所有内容，包括数据报告和探索。
当有新人来时，他们会去（官方）文档或社区讨论……
我建议设置一个 #welcome 标签，指向一些介绍性主题，以便轻松导航并帮助新用户入门，例如，从 tl0 到 tl1，了解社区氛围和领域。
文档可能应该有一个突出的起点，使用“文档系统”标签：tutorial explanation how-to reference
社区管理可以改名为社区建设（Community Building）……我不太喜欢“社区成功”（Community Success），原因不明。
3 个赞
manuel
2026 年2 月 19 日 05:14
16
是的，我以前在一个社区做过类似的事情，我也认为这是一种不错且灵活的指示入职路径的方式，而不是使用任何类别。就像这样
4 个赞
philh
2026 年2 月 19 日 18:27
17
我赞赏这项举措，并感谢让我们参与到这个过程中来。
关注了@stephtara 在Discourse上的历程后，我清楚地认识到Meta需要一个专门为新的社区建设者准备的地方。我不知道该叫它什么，但一个为那些第一次使用Discourse进行构建的人提供的温暖舒适的地方，将有助于减轻配置选项过载带来的不知所措的感觉。在这里提供帮助的人会知道，在回复这方面的帮助时，可能需要额外的努力和耐心。
也许我错过了，但一个配置选项文档类别，其中包含一个与“当前”管理区域相对应的索引，将会很棒。Discourse总是在发展。文档也应该通过跟上进度来实现同样的演变。
除了这个类别/标签的彻底改革之外，我希望在重新组织之后，对现有主题进行一次“重新梳理”。我在Meta上花费最多时间寻找答案的时候，是试图区分哪些信息与Discourse的当前状态相关，哪些是旧的且不适用的。我承认我的BBS（电子布告栏系统）是问题的一部分，但许多文档确实很难梳理。我确实感谢工作人员为改进文档所做和仍在做的工作，但许多/大多数似乎都需要改进。
为此，我建议将大多数看起来像文档的文档或主题标记为“需要审查”（Needs Review）标签。是的，这将是一大堆标签，但一旦审查过程完成，用户体验将得到极大的改善。我和其他人可能愿意协助这项工作。一个编辑标记序列可以帮助管理这个过程。
我在一个站点上使用这个：
摘要
需要审查 需要文本 需要引用 需要工作 准备发布
也许一个“已过时”（Out of Date）标签会有帮助。
@mcwumbly 再次感谢您发起这次重组并 让我们参与到这个过程中。
6 个赞
mcwumbly
2026 年2 月 21 日 15:01
19
把这个想法放在这里：
这可能值得开一个单独的主题，但我们可以在这里先作为所有这些更大变动的一部分进行更多讨论。
3 个赞
mcwumbly
2026 年2 月 25 日 10:48
20
mcwumbly:
2月23日当周
在此处更新类别组织以匹配第一帖中的内容，也许可以根据迄今为止的反馈做一些小的调整
期待在这里有更多关于实际感受的讨论反馈
根据反馈进行一些小的调整
我已经着手进行了第一轮更改，以便我们能开始一起感受实际效果。
我还更新了默认的侧边栏类别，但尚未对所有人应用，所以如果你想尝试将侧边栏设置为新的默认设置，可以这样做：
点击侧边栏中“Categories”（类别）旁边的编辑铅笔图标
在模态框的右下角选择“Reset to defaults”（重置为默认值）
根据需要进行调整
点击“:Save Changes”（保存更改）
请在接下来的大约一周内在这里分享您的任何反馈：
mcwumbly:
3月2日当周
如果整体感觉良好，则继续完善。或者
如果感觉完全不对，则恢复原状
2 个赞
同意。我认为配置更多是“一般支持”（除非是配置系统管理员层面的东西，比如你监听的端口等）。
（要求在给定类别中至少有一个来自给定标签组的标签），以避免子类别的倍增……
