大学のプログラムで単一のディスコースインスタンスを実行したいと考えています。そこでは、異なるトップレベルのカテゴリが異なるコースに対応し、アクセスはグループによって管理されます。コースのインストラクターと学習者がコースの一体感を持てるように、異なるコースの分離感を演出したいと考えています。そのため、インスタンスにはTeams/Slack/Mattermostのような、比較的分離されたチーム間をユーザーが切り替えるようなナビゲーション体験を提供したいです。私のインスタンスでは、UIが現在選択されているコースに関連するデータを強調するようにします。例えば、ユーザーはトップレベルのカテゴリのいずれかでほとんどの時間を過ごし、それらを選択すると、簡単に見ることができるサブカテゴリやチャットチャンネルがフィルタリングされます。
同様のニーズは、異なるカテゴリが異なる研究グループに対応するインスタンスでも生じます（私もそのようなインスタンスを実行したいと考えています）。
これを達成するために役立つ既存のツールはありますか？
興味深いユースケースですね！解決策としては、関連性のないカテゴリをミュートして、トピックリストに表示されないようにすることが考えられます。
実際にはミュートしたくありません。学生は複数のコースを同時に受講する可能性があり、それらすべてからの通知は問題ありません。むしろ、「今、コースXを見ています」という明確な印象を与えたいのです。
実際には、このようなものが必要なようです
ただし、選択可能な「ホーム」が必要です。
プライマリグループ＝選択されたホーム、ということで合っていますか？アカウント設定ページでユーザーがプライマリグループを変更できるように、user_selected_primary_groups を有効にする必要があります。
理想的には、もっと一時的で、公にはあまり見えないものが欲しいです。しかし、タイトルとフレアを使用しない場合、プライマリグループを切り替えるUIコンポーネントがチームセレクターとして機能するだろうと想像しています。
数日前に実験としてここで実行されていた、サイドバーの追加セレクターのようなものがそれには良いでしょう。
そうすることもできます。サイトのロゴをプライマリグループに応じて変更することもできます。私は、複数の大学がインスタンスを共有するサイトでそれを実行しました。トップバーにプルダウンがあるテーマコンポーネントを使用して、プライマリグループを選択できるようにすることもできます（そして、「グループ」の代わりに「クラス」と言うこともできます）。
@Anton_Akhmerov さん、ご自身で作業されますか、それとも外部に委託されますか？お知らせください！
ご自身で作業される場合は、Dev に移動して作業を進め、コミュニティに報告して他のメンバーからの意見を求めることができます。Dev に移動しましょう。
外部に委託される場合は、Marketplace に移動します。
この件は Community に移動して、ユースケースやニーズへの最適な対応方法についてさらに議論し、同様のニーズを解決した他のユーザーのためにスペースを確保するのが最善だと考えます。
その後、製品のギャップが特定され、ご自身で構築したり、提唱したりする価値があると思われる場合は、Feature や Dev で個別のトピックを立ち上げることができます。
この考え方でよろしいでしょうか？それとも、すでに「欠けている部分を構築する準備ができている」段階にいらっしゃいますか？
#コミュニティ も理にかなっています 
。この機能は、このようなリクエストの人気を考えると、コミュニティのニーズにある程度沿っているように見え、トリッキーなものです。
これに取り組む予定ですが、今のところ計画はかなり曖昧です。
フォローとして、Discourse の標準機能で皆様のニーズに最もよく応えられると思われる方法を以下に示します。皆様がお考えのものと 全く 同じではないかもしれませんが、議論の出発点として検討する価値はあると思います。
まず、いくつかの仮定を立てています。これらは有効な場合もあれば、そうでない場合もあります。間違っている点があれば、お知らせください。
これらが近いようであれば、まず全体的なレベルで以下のことを提案します。
アクセス制御：
グループとコースのユーザーエクスペリエンス：
個々のコースについては、カテゴリに固定トピックを配置し、コースへの参加方法を説明する：
管理は、最初は多少手間がかかります。新しいコースごとに、適切な権限を持つ誰かが以下を行う必要があります。
これらのうちいくつかは、軽量なツールで自動化できる可能性があります。メインの管理者チームが誰であるかによっては、API を呼び出すだけの帯域外の何かから始めるのが良いかもしれません。あるいは、Discourse にテーマコンポーネントやプラグインとして組み込まれた、より UI ベースの何かが必要かもしれません。しかし、ここではまずシンプルに始め、まず機能するプロセスを定義することに焦点を当て、その後にツールを設計することをお勧めします。
カテゴリのスケーリングは、ここで懸念される可能性があります。Discourse は、カテゴリ数が非常に多く（数百または数千）なると、パフォーマンスと UX に多少の粗さがあります。より多くのカテゴリにアクセスできるユーザーは影響を感じますが、アクセスが制限されているユーザーはそうではありません。これは、私が概説したようにカテゴリへのアクセスを制限する動機の一部です。
上記の点について、あらゆるフィードバックや質問をいただけると幸いです。
@mcwumbly様、詳細で思慮深いご説明ありがとうございます。
おっしゃることは、いくつか違いはありますが、まさに私が考えていることに近いです。
約5年間、単一のインスタンスをコースで運用してきた経験から、コースインスタンスをゼロから作り直すよりも、廃止されたディスカッションを非表示にしたり移動したりする方がはるかに手間がかからないことに気づきました。そのため、実際にはコースのディスコーススペースは固定されていますが、ほとんどのトピックにはライフサイクルがあります。
私は主に、コースチームはコースをセットアップするのではなく、管理する必要があると考えています。
私たちのコースには約200人の学生と、TAを含む約10人のコースチームがいます。これには少なくともいくつかのカテゴリが必要です。
サブカテゴリを使用することで、このニーズをカバーできると考えています。
インスタンス全体で上記のようなグループ化を作成することは可能であると認識していますが、それらすべてを単一のカテゴリにまとめる方がより合理的であるように思われます。
全体として、現在のディスコースの機能はこのユースケースによく適合していると思いますが、コースチームメンバーや学生が、すべてのコースを一度に見ているのではなく、単一のコースを見ているという感覚を提供する、純粋にフロントエンドの機能を除いては。
ドキュメンテーションテーマコンポーネントは、ユーザーがカテゴリに「入る」ことを可能にする点で少し似ていますが、カテゴリに「留まる」ことを容易にはしません。
はい、トピックを一括で移動するのは少し面倒ですが、カテゴリ全体を「現在のコース」から「過去のコース」に移動させるのは、おそらく非常に簡単だと思います。
これを行う利点は、各学期が新たに開始できることです。
ただし、これは欠点にもなり得ます。以前の学期のコンテンツが価値があるか有害だと考えるか、そしてチームが学期ごとに新しいカテゴリを作成するのにどれだけの労力がかかるかによります。
カテゴリが無期限に存続することは、確かにその労力を削減します。それが可能であれば、素晴らしいと思います。
そして、古いコンテンツが永遠に残ることが問題になった場合、それは「抱えていて嬉しい問題」かもしれません。後で私が提案したモデルに移行するのは、それほど難しくないはずです。
ここのあなたの理論は健全だと思います。
各コースカテゴリ内に、それらのアクティビティごとにサブカテゴリを設けるのは合理的だと思います。
追加の複雑さが正当化されるとどれだけ確信しているか、そしてそうである場合、それが適切な形式であるかどうかによって、再び少し異なります。
代わりに、お知らせには制限付きタグを使用することもできます。これにはいくつかの利点があります。
最後の2つは、カテゴリの代わりにグループPMで処理できます。
どちらのオプションも検討する価値があると思います。それらの間にはいくつかのトレードオフがあります。
設定を深く進めるにつれて、問題に遭遇したら質問を続けてください。
そして、どちらの方向を選択して開始するにしても、どのように進んでいるかについて時折アップデートを聞かせていただけると嬉しいです！
テーマコンポーネントは、たとえばアイコンを変更して、グローバルではなくコースのホームページに移動させることができます。
私は教育学の教授だった頃、インストラクショナル・テクノロジーのコースを教えるためにDiscourseを使い始めました。
コース教材のためにカテゴリを使用し、学生には返信としてリンクされたトピックを作成してもらい、課題を提出してもらいました（公開カテゴリで）。学期レベルのトピックでは、シラバスが正規のコース教材を参照し、いつ何をするかを指示していました。その後、採点対象のトピックを示すためのタグセットを使用し、私がトピックに「いいね」したかどうかで、課題を承認したかどうかを示すスクリプトを作成しました。
大学のLMSからCSVを更新して、そこに成績をアップロードしやすくするスクリプトを作成しました。
私が最も気に入っていたと思うこと、そしてもし私がもっと優れた学者であったなら（そしてその仕事を辞めていなかったら）書いたかもしれないことは、コースの途中で課題を更新して、不明瞭な点を修正していたことです。来年まで待って改善するのではなく。そして、すべての編集はその履歴で利用可能だったので、学生は私が編集を加える前に行ったバージョンであっても、好きな課題のバージョンを自由に使うことができました。コースをその場で改善することは、1年間待って問題点を覚えていられることを願うよりも、素晴らしいアイデアだったと今でも思っています。
