大学のプログラムで単一のディスコースインスタンスを実行したいと考えています。そこでは、異なるトップレベルのカテゴリが異なるコースに対応し、アクセスはグループによって管理されます。コースのインストラクターと学習者がコースの一体感を持てるように、異なるコースの分離感を演出したいと考えています。そのため、インスタンスにはTeams/Slack/Mattermostのような、比較的分離されたチーム間をユーザーが切り替えるようなナビゲーション体験を提供したいです。私のインスタンスでは、UIが現在選択されているコースに関連するデータを強調するようにします。例えば、ユーザーはトップレベルのカテゴリのいずれかでほとんどの時間を過ごし、それらを選択すると、簡単に見ることができるサブカテゴリやチャットチャンネルがフィルタリングされます。
同様のニーズは、異なるカテゴリが異なる研究グループに対応するインスタンスでも生じます（私もそのようなインスタンスを実行したいと考えています）。
これを達成するために役立つ既存のツールはありますか？
興味深いユースケースですね！解決策としては、関連性のないカテゴリをミュートして、トピックリストに表示されないようにすることが考えられます。
実際にはミュートしたくありません。学生は複数のコースを同時に受講する可能性があり、それらすべてからの通知は問題ありません。むしろ、「今、コースXを見ています」という明確な印象を与えたいのです。
実際には、このようなものが必要なようです
ただし、選択可能な「ホーム」が必要です。
プライマリグループ＝選択されたホーム、ということで合っていますか？アカウント設定ページでユーザーがプライマリグループを変更できるように、user_selected_primary_groups を有効にする必要があります。
理想的には、もっと一時的で、公にはあまり見えないものが欲しいです。しかし、タイトルとフレアを使用しない場合、プライマリグループを切り替えるUIコンポーネントがチームセレクターとして機能するだろうと想像しています。
数日前に実験としてここで実行されていた、サイドバーの追加セレクターのようなものがそれには良いでしょう。
そうすることもできます。サイトのロゴをプライマリグループに応じて変更することもできます。私は、複数の大学がインスタンスを共有するサイトでそれを実行しました。トップバーにプルダウンがあるテーマコンポーネントを使用して、プライマリグループを選択できるようにすることもできます（そして、「グループ」の代わりに「クラス」と言うこともできます）。
@Anton_Akhmerov さん、ご自身で作業されますか、それとも外部に委託されますか？お知らせください！
ご自身で作業される場合は、Dev に移動して作業を進め、コミュニティに報告して他のメンバーからの意見を求めることができます。Dev に移動しましょう。
外部に委託される場合は、Marketplace に移動します。
この件は Community に移動して、ユースケースやニーズへの最適な対応方法についてさらに議論し、同様のニーズを解決した他のユーザーのためにスペースを確保するのが最善だと考えます。
その後、製品のギャップが特定され、ご自身で構築したり、提唱したりする価値があると思われる場合は、Feature や Dev で個別のトピックを立ち上げることができます。
この考え方でよろしいでしょうか？それとも、すでに「欠けている部分を構築する準備ができている」段階にいらっしゃいますか？
#コミュニティ も理にかなっています 
。この機能は、このようなリクエストの人気を考えると、コミュニティのニーズにある程度沿っているように見え、トリッキーなものです。
これに取り組む予定ですが、今のところ計画はかなり曖昧です。
フォローとして、Discourse の標準機能で皆様のニーズに最もよく応えられると思われる方法を以下に示します。皆様がお考えのものと 全く 同じではないかもしれませんが、議論の出発点として検討する価値はあると思います。
まず、いくつかの仮定を立てています。これらは有効な場合もあれば、そうでない場合もあります。間違っている点があれば、お知らせください。
これらが近いようであれば、まず全体的なレベルで以下のことを提案します。
アクセス制御：
グループとコースのユーザーエクスペリエンス：
個々のコースについては、カテゴリに固定トピックを配置し、コースへの参加方法を説明する：
管理は、最初は多少手間がかかります。新しいコースごとに、適切な権限を持つ誰かが以下を行う必要があります。
これらのうちいくつかは、軽量なツールで自動化できる可能性があります。メインの管理者チームが誰であるかによっては、API を呼び出すだけの帯域外の何かから始めるのが良いかもしれません。あるいは、Discourse にテーマコンポーネントやプラグインとして組み込まれた、より UI ベースの何かが必要かもしれません。しかし、ここではまずシンプルに始め、まず機能するプロセスを定義することに焦点を当て、その後にツールを設計することをお勧めします。
カテゴリのスケーリングは、ここで懸念される可能性があります。Discourse は、カテゴリ数が非常に多く（数百または数千）なると、パフォーマンスと UX に多少の粗さがあります。より多くのカテゴリにアクセスできるユーザーは影響を感じますが、アクセスが制限されているユーザーはそうではありません。これは、私が概説したようにカテゴリへのアクセスを制限する動機の一部です。
上記の点について、あらゆるフィードバックや質問をいただけると幸いです。
