本示例站点是一个提案，旨在探讨如何推进我参与的一个志愿者项目的社区论坛。目标是从仅用于交流的社区论坛，转向以社区为核心的项目运作模式。
分类包括：讨论、分享和行动。团队区域仅做标记。其理念是让团队在整个论坛中保持可访问性，而不通过分类将社区割裂。
针对本提案，我还将Assign（指派）功能调整为Lead（主导），并将Solved（已解决）插件调整为Completed（已完成）。默认情况下，在主题上标记“已解决”会取消指派，这在此场景下效果良好：因为“主导”仅显示未完成的活动主导项。
这也与使用Event（活动）功能来安排活动相契合。此处唯一的调整是将Going/Not going（参加/不参加）重命名为Join（加入）和Leave（退出），用于表示参与情况。默认情况下，它会在Upcoming events（即将举行的活动）日历中列出活动，这看起来非常实用。
您是如何设置 Discourse 以实现社区协作的？除了常规的论坛设置之外，我很想听听更多的方法！
非常感谢你分享这篇文章。我正在为一个非常类似的使用场景规划 Discourse 设置，看到你的做法让我深受启发。
我打算不在这里发布我的想法和解决方案，因为最好另开一个主题来讨论，这样可以保持本文专注于探讨你的观点。
我喜欢它看起来如此简洁明了。
你将内容分为“交流”、“分享”和“行动”，这个划分非常清晰，我很喜欢这种明确性。不过，我可能不会采用这种方式，因为我不确定它是否真正符合我们社区的实际情况。我不确定这种区分能帮到谁，比如，什么时候有人会想浏览“交流”却忽略“分享”？
你的左侧栏设计得很棒……这是主题组件还是自定义主题？
既然顶部侧边栏已经列出了“分类”，为什么还要在顶部菜单中添加“分类”呢？
你将“已解决”插件改编为“已完成”的想法非常有趣，我会尝试一下。
感谢你的反馈，Jonathan！是的，确实不应该将这个主题设置成各种解决方案的集合，我已经调整了主贴的标题和正文！
关于第 2 点：是的，我并不是建议直接使用这些相同的术语。不过我有一个总体建议，那就是不要通过一级分类将社区划分为不同的子群体。我制作了一张思维导图来直观展示这一点。在我看来，任何可以放在类似白色气泡中的内容，都能很好地支持这种布局：
第 3 点：我正在使用 自定义布局插件 及其当前所有的小部件：分类列表、个人资料、自定义 HTML 和主题列表。因此，列出标签（社区、设计、开发、营销）的导航菜单是一个自定义 HTML 列表。
第 4 点：我仅在桌面视图下使用侧边栏，而不在移动设备上使用，这就是为什么我还在顶部导航栏中显示分类。此外，可能还有一些分类，我不希望在侧边栏菜单中给予同样的突出显示。
我非常欣赏你的思维方式。当我刚开始学习编写 Discourse 插件时，我也曾犯过同样的错误，过于关注“分类”（categories）。我认为，想象一下在现实生活中执行我们在 Discourse 上所做的操作会很有帮助。试想一下，进入一个分类并“创建新主题”（creating a new topic）。这对我来说感觉很不自然。我记不起在现实生活中做过类似的事情。我觉得“发起对话”或“提出问题”这样的行动要自然得多。
行动应该是在现实生活中真正感觉自然的事情。“创建主题”（creating a topic）感觉机械，甚至对我而言有点粗鲁。这就是为什么我正在构建一个 API，用我目前正在开发的插件中的自定义操作来替换编辑器（composer）的默认操作。我也很喜欢你关于创建有目的的社区的想法。我觉得我的目标——基于 Discourse 创建一个协作式词典——也朝着类似的方向发展。Discourse 需要以某种方式进行定制，否则它太像一个 Facebook 群组了，而 Facebook 群组的摩擦成本非常低。
我希望 couchers.org 能够成功。我曾在三月抵达台北时使用过 couchsurfing.org，之后就没再用过，但我从其他旅行者那里听说它曾经历过一场不小的动荡 
风险投资（VC）资金毁了一切 
不错！
这与我们在 Pavilion 使用 Discourse 管理项目的方式非常接近。我们使用：
我们还使用 Layouts Plugin 和 Layouts Category List Widget 来构建侧边栏
我很好奇，你为什么选择不使用移动布局视图？
我们选择完全隐藏分类下拉菜单（通过主题组件实现）。我很好奇，你是否对分类列表组件进行了调整以选择特定分类？或者你是否使用了 excluded_categories 设置？我曾考虑添加一个 included_categories 设置（或类似功能），因为这可能对某些人很有用。
我最近实际上在 thepavilion.io 启用了三级分类体系，以实现不同的知识库组织方式。我们之前采用的是：
knowledge
layouts
custom-wizard
category-highlighter
现在已改为：
knowledge
plugins
layouts
custom-wizard
themes
category-highlighter
我此前一直抵制这一转变，因为三级分类更复杂，特别是对于插件和主题的处理。例如，分类列表组件之前不支持三级分类（我最近才添加了支持）。
然而，出于组织原因，我们现在在知识库中需要三级分类（例如，我们需要按分类从 API 中提取特定的知识主题）。正如在基于项目/工作的 Discourse 论坛中可能预期的那样，分类可能会受到组织需求的影响，而不是像以讨论为主的论坛那样仅围绕讨论主题进行划分。
其实我对当前的移动端视图已经很满意了。我也认为在适配方面不必过于花哨。因此，网站的基本导航可以通过标准导航菜单来实现。
我刚才看了一下，作为反馈，我发现理解其工作原理有些困难。听起来这似乎是另一个硬编码的 HTML 菜单。我也希望能避免这种情况。
是的，我在小部件设置中排除了一些分类。我认为“包含”的方式会更直观，因为大多数设置都是这样工作的。也许在首次启用该小部件时，可以自动填充所有现有分类的列表？
总的来说，我真的很喜欢 discourse_layouts 插件 
，并在那里的小部件部分留下了更多反馈：
太棒的反馈！我已经在 thepavilion.io 上回复了