クライアントが、3つのサブコミュニティを持つ単一のブランドコミュニティをホストしたいと考えています。
これを成功させた方はいらっしゃいますか？グループとカテゴリのどちらが最適でしょうか？
サブコミュニティは、それぞれユニークなブランド設定、異なるメンバーエクスペリエンス、そして異なる機能と活用の必要性があります。
3つのコミュニティすべては、同じコミュニティマネージャーまたはチームによって管理されます。
どのように実施したか、共有していただける例があればぜひお聞かせください。
「いいね！」 6
権限設定のためには3つのグループを作成する必要があります。その後、3つの「サブコミュニティ」のために3つのカテゴリを作成する必要があります。
例：
作成するもの：
グループ1
グループ2
グループ3
次に作成するもの：
カテゴリ1（グループ1用） - カテゴリのセキュリティ権限：「グループ1 作成/返信/表示」
カテゴリ2（グループ2用） - カテゴリのセキュリティ権限：「グループ2 作成/返信/表示」
カテゴリ3（グループ3用） - カテゴリのセキュリティ権限：「グループ3 作成/返信/表示」
「いいね！」 2
これには、個別のフォーラムが必要になりますね。
「いいね！」 3
@ondrej さんに加えて、コミュニティごとに 2 つのグループが必要になります。メンバー グループには、承認されたマネージャーをメンバー グループのオーナーとして設定します。次に、コミュニティ マネージャー グループが必要になります。これはカテゴリ モッドにもなります。
セルフホストの場合、Category Restricter プラグインを使用して、カテゴリ モッドとフルサイト モッドの機能を拡張できます。これにより、カテゴリへの投稿をユーザーにサイレンスさせる機能が追加されます。
したがって、完全な停止と完全なサイレンスを支援するために、メインサイトチームが必要になります。
「いいね！」 2
これらのサブコミュニティ間でどのような種類のインタラクションを期待しますか？
以下のような質問を考えています。
-
一方のコミュニティのメンバーが、他のコミュニティに自由に 参加できるようにしますか？
メンバーにとって、それは一つの大きなコミュニティのように感じられるべきですか？それとも、一方のコミュニティに参加する場合と、もう一方のコミュニティに参加する場合で、完全に異なるコミュニティ間を移動しているように感じるべきですか？ -
一方のコミュニティでの会話が、他のコミュニティにまたがって展開できるようにしますか？
例えば、ディスカッションのクロスリンクを多く期待したり、ある会話の一部を別の会話に引用したりすることを期待しますか、それとも奨励しますか？それとも、そのような行動は起こりにくい、奨励する価値がない、あるいは奨励すべきでないと考えますか？ -
それぞれのコミュニティが利用すると予想される、異なる機能や機能の例を共有できますか？
ここで考えられることがいくつかありますが、あなたが考えていることをさらに説明するのに役立つ例を共有していただけると幸いです。
「いいね！」 7
素晴らしい質問です 
メンバーが他のコミュニティに自由に交流できることを望みますか？
いいえ、あるコミュニティのメンバーが他のコミュニティに参加したり交流したりすることを望む可能性は非常に低いです。
あるコミュニティでの会話が他のコミュニティにまたがることができることを望みますか？
いいえ、クロスオーバーはありません。それらは完全に別個の主題であり、ターゲットメンバーも異なります。
それぞれのコミュニティが使用すると予想されるさまざまな機能や機能の例を共有できますか？
- 3つのユニークなコミュニティへのリンクを持つ、単一のブランド化されたランディング/ホームページ
- 翻訳プラグイン
- SSO
- トピック
- プライベートグループ
- あるコミュニティの機能を他のコミュニティに簡単に複製する機能
- メンバーが3つのコミュニティのうちどれにメンバーになりたいかを自己選択するための、潜在的な開発作業
- コミュニティマネージャーが、必要に応じて、3つのコミュニティすべて、または1つのコミュニティに変更を加えることができる機能
- あるコミュニティ（最初は）のための分析ハブ Creating an Analytical Hub using Categories, Approval Process and Upvoting
「いいね！」 4
興味深いですね。
これらを3つの別々のサイトとして維持する方が良いのではないかと疑問に思う点があります。それは除外されましたか？もしそうなら、なぜですか？
私の考えはこうです。これらすべてを1つのサイトにまとめる動機は、管理チームの利便性のようです。しかし、それに対処する他の方法があるかもしれません。複数のコミュニティに構成変更を適用することは、他の方法で解決できる技術的な問題のように思えます。そして、それらを別々に維持することで、各コミュニティが異なるニーズを持っていると判断された場合（コミュニティが進化するにつれてさらに分岐する可能性があります）、それぞれで異なることを行うためのより大きな自由が得られます。
一方で、私が物事を特徴付けた方法には、いくつかの例外のヒントが見られます。
3つのユニークなコミュニティへのリンクを持つ単一のブランド化されたランディング/ホームページ
これはなぜ重要ですか？
これらのコミュニティの人々が互いに完全に分離されている場合、これらすべてを1か所で見ることによって誰が利益を得るのでしょうか？
おそらく、ここでの答えは、私がこれまで見落としていたいくつかの重要な洞察につながるでしょう。
繰り返しますが、これは別の方法で対処できるのではないかと思います。3つのリンクを持つホームページだけで、動的に読み込まれるコンテンツがある場合、それはサイト外で実装できるかもしれません。
さて、上記を再検討しても役に立たないと感じ、これらすべてを1つのサイトの下に置くという決定がなされた場合、あなたが共有してくれたことを文脈として念頭に置きながら、どのようにそれを行うかについての元の質問に戻ることができます。
「いいね！」 1
デイブ、これは本当に参考になります。フィードバックと提案に感謝します！
現時点では、まさに発見の段階であり、これらのコミュニティがどのように機能するか（メンバーの視点、コミュニティマネージャーの視点、組織の視点から）を正確に把握しようとしています。この段階では何も除外されていません。
あなたは多くの興味深い点を挙げてくれました。関係者にいくつか質問があります。
ここで学んだことと、それらの明確化のための質問への回答を提示します。その明確さが得られたら、このスレッドに戻ってきます。最善のアプローチを見つけるのが楽しみです 
「いいね！」 3
こちらについてもう少し詳しく教えていただけますか？ このスレッドでの有益なアドバイスや質問の後、クライアントに2つの選択肢を提示することにしました。
- 複数のコミュニティを持つ単一サイト
- 複数のサイト
単一サイト構成を検討する主な理由は、1人のコミュニティマネージャーが3つすべてを管理できるようにするためです。コストが動機ではありません。
「いいね！」 3
まずはリーンなアプローチをお勧めします。
つまり、特定のユースケースに特化したソリューションを設計し、それを実践し、反復することが役立つということです。それがコミュニティチーム向けの本格的なクロスコミュニティダッシュボードに進化するかもしれませんが、あるいは「十分な」ものがそれよりもはるかに小さいものになるかもしれません。
例えば、CMはまずDiscourse Hubを使用して、3つのコミュニティすべてからのフィードを確認し、それぞれに注意が必要なフラグがいつ発生したかを確認できるようになります。
さらに一歩進んで、それらのいずれかのチャットチャンネルを「ホームベース」として使用し、モデレーションを支援するために、まずすべてのコミュニティからのレビューキューの通知フィードを構成することができます。
メトリクスとレポートについては、各コミュニティの管理UIエリアまたはデータエクスプローラーレポートへのブックマークのセットから始めるのが簡単な出発点になる可能性があります。
さらに一歩進んで、Discourse Automationを使用してAI生成レポートを設定し、各コミュニティ内のさまざまなソースからのデータを集約したレポートをPMにプッシュすることができます。それでも3つの別々のPMになりますが、移動する場所は少なくなります。
さらに一歩進んで、AIペルソナ内のツールを使用して、コミュニティ全体からデータを取得し、それらのデータ全体から単一のレポートを作成することができます。
多くのビルディングブロックが用意されていると思います。それらを使用して何かをまとめるのはより多くの作業のように思えるかもしれませんが、それはまさに必要なものを構築し、どの部分をより早く配置することが重要かを優先する機会でもあります。
そして、それらすべてが価値があることが証明され、さらに多くのものが望まれる場合は、カスタムプラグインのように、よりカスタムなものが構築され、望ましい結果が得られるという自信が高まる可能性があります。
「いいね！」 3