我想为大学项目运行一个单一的 Discourse 实例，其中不同的顶级类别对应不同的课程，并且访问由组管理。为了让课程讲师和学习者能够对课程有一个统一的认识，我希望提供一种隔离不同课程的体验。因此，我希望我的实例提供类似于 Teams/Slack/Mattermost 的导航体验，其中有相对隔离的团队，用户需要从一个团队切换到另一个团队。对我的实例而言，这意味着 UI 会强调与当前选定课程相关的数据。因此，例如，用户大部分时间都在一个顶级类别中，选择一个类别会过滤他们可以轻松看到的子类别和聊天频道。
当不同类别对应不同研究小组的实例时，也会出现类似的需求（我也想运行一个这样的实例）。
有哪些现有工具可以帮助实现这一点？
有趣的用例！一个可能的解决方案是简单地静音不相关的类别，这样它们就不会出现在主题列表中。
我实际上不希望它们被静音：学生可能会同时参加多门课程，并且所有课程的通知都可以。而是我希望给“现在我正在看X课程”一个更清晰的印象。
实际上，我似乎需要类似这样的东西
但需要有一个可选择的“主页”。
似乎主要组 = 选择的主页，对吗？您需要启用 user_selected_primary_groups，以便用户可以在其帐户首选项页面上更改其主要组。
理想情况下，我想要一些更短暂、不那么公开可见的东西。但是，我想象一下，如果我不使用标题和Flair，那么一个切换主组的用户界面组件可以作为团队选择器。
就像几天前在这里作为实验运行的侧边栏选择器那样，那将很棒。
你也可以这样做。你也可以根据他们的主组更改网站徽标；我曾为一个拥有多个大学共享实例的网站做过这样的事情。也许你会有一个主题组件，在顶部栏有一个下拉菜单，让他们选择他们的主组（也许称之为“班级”而不是“组”）。
@Anton_Akhmerov 你是打算自己做，还是愿意付钱请人帮你做？告诉我！
如果你想自己做，我想把它移到 Dev，这样你就可以在那里进行工作，并向社区汇报，获得其他成员的意见。我们把它移到 #dev。
如果你想付钱请人，我会把它移到 #marketplace。
我认为最好将其移至 Community 并进一步讨论您的用例，如何最好地满足您当前的需求，并为可能有类似需求的人腾出空间来解决他们的问题。
然后，如果确定了您认为足够重要而需要自己构建或倡导的产品差距，我们可以为这些想法在 Feature 和/或 Dev 中创建单独的主题。
这是否符合您的想法？或者您已经处于“我已准备好构建缺失的部分”阶段？
Community 也有道理 
。该功能看起来很棘手，考虑到类似请求的受欢迎程度，它似乎在一定程度上符合社区的需求
我确实计划着手处理这个问题，但到目前为止，我的计划还比较模糊。
作为跟进，我想说明一下如何通过 Discourse 的开箱即用功能来最好地满足您的需求。这可能不完全符合您的设想，但我认为它值得作为讨论的起点。
首先，我做了一些假设，这些假设可能有效，也可能无效。请告诉我我哪里说错了：
鉴于这些假设接近实际情况，以下是我的建议，首先是高层次的：
访问控制：
群组和课程的用户体验
对于个别课程，在类别中置顶一个主题，解释如何加入课程：
管理工作最初会有些繁琐，因为对于每个新课程，拥有适当权限的人都需要：
其中一些可以通过轻量级工具进行自动化。根据主要管理团队是谁，可能需要从一些带外工具开始，这些工具直接调用 API。或者，您可能需要一个更基于 UI 的东西，它作为主题组件或插件内置到 Discourse 中。但我建议从精简开始，首先专注于定义一个可行的流程，然后围绕该流程设计工具。
类别扩展可能是一个令人担忧的问题。当类别数量过多（数百或数千）时，Discourse 在性能和用户体验方面确实存在一些粗糙之处。可以访问更多类别的用户将感受到这种影响，而访问权限有限的用户则不会。这也是限制对类别访问的部分原因，如我所述。
非常期待听到您对以上内容的任何反馈或疑问。
嘿 @mcwumbly，感谢您提供的详细而周到的描述。
您描述的确实与我心中所想非常接近，但有几处不同。
通过运行一个课程实例大约5年，我意识到隐藏或移动过时的讨论比从头开始重新创建课程实例要省力得多。因此，实际上课程的 discourse 空间是固定的，但大多数主题都有生命周期。
我主要设想的是，课程团队需要管理课程，而不是设置课程。
我们的课程大约有200名学生，课程团队约有10人，包括助教。这至少需要几个类别：
我相信使用子类别将满足这一需求。
我意识到可以创建一个实例范围的上述分组，类似于您所描述的，但似乎更合理的是将所有这些内容放在一个类别中。
总而言之，我认为当前的 discourse 功能非常适合这个用例，除了纯粹的前端功能，即需要让课程团队成员或学生感觉他们正在查看一个课程，而不是同时查看所有课程。
文档主题组件在某种程度上是相似的，因为它允许用户“进入”一个类别，但它不允许用户轻松地“停留在”一个类别中。
是的，批量移动主题有点麻烦，但我认为将整个类别从“当前课程”重新定位到“过去课程”会很容易。
这样做的优点是每个学期都可以重新开始。
但这可能也是一个缺点，取决于您是否认为上一学期的内容有价值或有害，以及您的团队为每个学期创建新类别的努力程度。
让类别永久存在肯定会减少这种努力。如果可行，听起来不错。
而且，如果永远保留旧内容成为一个问题，也许这是“一个好问题”，稍后切换到我建议的模型应该不会太糟糕。
我认为你的理论是合理的。
在每个课程类别中为每项活动设置子类别似乎是合理的。
我认为这再次取决于您对额外复杂性是否值得的信心，如果值得，那么这种形式是否正确。
您可以使用受限标签来发布公告，这有一些好处。
最后两项可以通过群组私信而不是类别来处理。
我认为这两个选项都值得考虑。它们之间存在一些权衡。
在深入设置的过程中，遇到问题时请继续提问。
无论您选择哪种方向开始，我都希望偶尔能听到关于进展情况的更新！
主题组件可以更改图标，并使其转到课程主页而不是全局主页。
我开始使用 discourse 来教授教学技术课程，当时我是一名教育学教授。
我使用一个类别来存放课程材料，并让学生通过“回复即链接主题”的方式提交他们的作业（在公开类别中）。在一个学期级别的主题中，教学大纲会引用规范的课程材料，并说明何时做什么事情。然后，我使用了一组标签来指示哪些主题需要评分，并编写了一个脚本来查看我是否喜欢某个主题，以表明我是否批准了这项工作。
我编写了一个脚本，可以更新大学学习管理系统 (LMS) 中的 CSV 文件，以便于将成绩上传到那里。
我认为我最喜欢的一点，如果我当时是一名更好的学者（并且没有离开那份工作），我可能会写下来，那就是我会在课程进行中更新作业，以修复不清楚的地方，而不是等到明年再进行改进。由于所有的编辑都可以在历史记录中找到，学生可以自由地选择他们想要做的任何版本的作业（或者在我编辑之前做的）。我仍然认为，在课程进行中改进课程，而不是等到一年后才希望记住问题所在，这是一个绝妙的主意。
