ええ、その通りだと思います。まずはトピック外のチャンネルを1つと緊急のチャンネルを1つから始めて、どうなるか見てみましょう。
また、各チャットをスレッドに変換できるため、盛り上がった会話が必ずしもストリーム内で見えなくなるわけではないことも忘れないでください。
もしこのような種類の質問とそのやり取りが長期的に見て興味深いものであれば、トピック外のチャットチャンネルを1つだけ用意し、このような質問はカテゴリに入れる方が良いかもしれません。これは、ここでの#bugカテゴリの扱い方と同じです。注意深く監視されています。
移行計画について、ぜひお聞かせください。すでにそのための新しいトピックを作成されましたか？
まだです、非常にゆっくり進めています。セットアップはまだ終わっていません。1月か2月までには数人をオンボーディングできるものができれば嬉しいです！（もちろん、驚くほど早く物事が進めばここで最新情報をお知らせします。）
この段階で私が本当に困っていることの一つは、ディスコース（Discourse）が中心となる新しいエコシステムの中で、既存のFacebookグループにどのような位置づけを与えるかということです。
ご心配なく！最初は大変な作業ですから。移行にどのように取り組むか、ぜひご報告ください。
より小規模なFacebookグループでは、まずDiscourseのセットアップを試用してもらうために、ユーザーを非公開で招待しました。これにより、設定や構成のいくつかを微調整するのに役立ちました。
ローンチ後、数週間は2つのシステムを並行稼働させ続けました。Facebookに投稿する人には、Discourseプラットフォーム上の関連トピックやリソースへのリンクを貼るよう、多大な努力を払い、それによってより多くのトラフィックを誘導しました。
その初期期間の後、Discourseへの登録リンクと、全体的な参加状況に関する初期統計情報を含む、もう一つのピン留めメッセージを投稿しました。
その後、さらに期間が経過し、Facebookでの新規投稿や返信はモデレーターの承認を必要とするようにしました。FBグループはアーカイブリソースとしてのみ存在し、現在行われているすべての会話は新しいプラットフォームで行われていること、また、更新されたドキュメントやその他のリソースの大きなキャッシュをどこに投稿したかを伝えるピン留めメッセージを投稿しました。私たちにとっては、それがユーザーのプラットフォーム切り替えを大きく促進する要因となりました。
「チャットサポート」の環境には少し警戒心を抱いています。
同感です。チャットは、社内環境、例えばソーシャルなバックチャンネルや「今日のランチはどこに行く？」といった用途では意味をなすかもしれません。しかし、ほとんどの人が非同期で参加するサポートやコミュニティの文脈では、あなたが警戒するのは正しいと思います。何か深刻なことに対してチャットを提供すると、即時応答が期待される可能性があります。ヘルパーが監視すべきチャネルが増え、トピックとして保存する価値のあるチャットをモデレートし、変換するための手間が必要になります。
チャットを純粋に雑談用のオフルトピックストリームとして利用する価値はあるかもしれません。あるいは、チャットなしで開始し、必要性が自然に生じるかどうかを確認することも考えられます。後で頭痛の種になった場合にそれを取り除くよりも、何かを控えておく方が簡単です。
サポートのためにチャットを利用することについてのここでの注意喚起には同意します（そして、私がDiscourseに参加したとき、チャットが私の主な焦点でした！）。
おふざけに最適だと思います。
チャットのもう一つの確かなユースケースは、より高い信頼レベルに達したメンバー間です。コミュニティの他のメンバーとよりオープンに関わる際、ヘルパーがお互いをサポートするための場所を持つことは役立つかもしれません。
そのバリエーションの一つがコミュニティチーム自体です。管理者とモデレーターがお互いに調整するためにチャットを利用することです。
まずはソフトローンチ、最小限のDiscourseセットアップ、ボランティア/厳選されたユーザーから始めるつもりです。Facebook上で問題となっている一部のアクティビティを移行することも検討しています。例えば、「初心者」グループはFacebookの技術的な問題で手詰まりになっています。また、猫が死んだり寛解したりした際に中古品や余ったインスリンを譲渡することに関するものはすべて問題となります。ですから、それらは人々を引きつけるための良い候補です。
数週間ではなく、数ヶ月にわたって両方を並行して運営するつもりです。そして、はい、Facebook側で「摩擦」を加えて、Discourseへの投稿をより魅力的にする方法を考えているのは確かです。
しかし、Facebook上のグループを閉鎖することを目標とするのは良い戦略だとは思っていません。それは大きく、活発で、非常に目立ち、高いランキングを得ています。ですから、Discourseコミュニティと競合することなく、それをDiscourseコミュニティへのゲートウェイに変える方法を見つける必要があります。
はい、これらは間違いなくFacebook側での私たちのユースケースです。管理者グループチャット（管理チームがかなり大規模で、人々が圧倒されていると感じていたため、「新規メンバー」「モデレーション」などに分割されています）が複数あり、アクティブなヘルパー向けの別のチャットもあり、そこで彼らは互いにサポートし合い、私たちは彼らにベストプラクティスに向けて「指導」します。
結局、ある時点で管理者チームのために秘密のFacebookグループを作成する必要がありましたが、それはもうあまり使われていません。
もしFacebookでサブグループへのアクセス権があれば、「ヘルパー」のサブグループを間違いなく欲しかったでしょう。チャットよりも長く残るコンテンツを持つ空間を持つことに価値があると思うからです。また、忙しいチャットでは時間の霧の中に消えがちな「進行中のケース」についての議論にも役立ちます。
ありがとうございます！
メタでこれをオープンに進めているのは素晴らしいことだと思います。あなたの経験から多くの人が恩恵を受けるでしょう。
私もあなたが成功することを心から願っています。ご存知のように、飼っている4匹の猫の世話であなたたちのコミュニティに参加する必要があるのですから、もし許可してくれればぜひ参加したいです！
しかし、二度とFacebookに戻りたくはありません。
しかし、Facebookでの存在感を維持したいというあなたの考えは正しいと思います。他の場所にもいるのであれば、それらもアクティブに保ちたいでしょう。バランスを見つけるのは簡単ではありませんが、可能です。
デイブが、あなたのヘルパーたちがこの移行において大きな役割を果たすことができると私に思い出させてくれました。もし、あなたたちのうち十分な数の人が毎日あなたのDiscourseサイトに集まって人々を助け、皆が必要とするものを提供することに専念し、そしてあなたたちが内部でのコミュニケーションにDiscourseのみを使用するなら、あなたのDiscourseサイトは勢いを増すでしょう。
ハハ、ちょうど今日、もしよければ覗きに来てみたらどうかなと考えていたところですよ 
はい！
ステファニー - もし後でまとめて書くことに興味があれば、良いケーススタディになるかもしれません。
また、フォーラムの設定を開始したら、時系列の「開発ログ」を保持することを強くお勧めします。それは単一のテキストファイルと同じくらい簡単なもので構いません。機能の有効化、設定の調整、権限の変更を行うたびに、詳細とキーワードを添えて日付入りのメモを作成してください。「どうやってこれを実現したんだっけ？」と後で疑問に思ったときに、非常に役立ちます。
しまった、もう遅すぎました！でも素晴らしいアイデアですね！すでに何をどこで変更したのか分からなくなっています😭
設定変更の自動的な内部ログのようなものはどこかにありませんか？
また、手順が正しいかどうかも定かではありません。Discourseのインストールが現在正しいドメイン/サブドメインにないため、もし移動するときにすべてが壊れるとしたら、正しいドメインに設定することから始めるべきかもしれません。
これにより、どのサブドメイン名を使うか、サブドメインを使うかメインドメインに置くか…という厄介な問題が開かれます🤯
確かにあります！管理者 → セキュリティ → ログとスクリーニング (または .../admin/logs/staff_action_logs) を確認してください。
そこのフィルターオプションも確認してみてください。
そのログで何が行われたかを確認できますが、私は自分の言葉で、自分の考えも含めて記録を残しておくのが好きです。
今日、私が考えているのは、いつもの過剰設計と最適化の罠に陥るのではなく、もっと違うアプローチをとるべきではないかということです。なぜかって？それは、設定を深く掘り下げ、Metaで読む情報が増えるほど、認知的過負荷に陥り始め、これをすべて整理する時間が… 2027年までに訪れるのかと絶望し始めるからです😅
そこで、自分に問いかけました。他にどんなアプローチがあるだろうか？
別の方法としては、DiscourseにFacebookコミュニティの既存の構造をほぼそのままコピー＆ペーストすることから始め、そこから進めるという方法があります。Discourseの大きな利点は柔軟性にあると思います。新しいカテゴリーが必要ですか？作成すれば、もし以前から存在していたならそこに入るべきだった投稿の山を（私が間違っていなければ）一括で割り当てることができます。サブカテゴリーをトップレベルにしたいですか？移動させましょう。タグをカテゴリーにしたいですか？変換するか、それが不可能なら新しいカテゴリーを作成し、そのトピック群を対象に一括割り当てができるはずです。特定のカテゴリーでメンバーを統制するためにテンプレートを追加したいですか？それもできます。
Facebookでコミュニティを立ち上げたとき、私はすでにFacebookグループの機能（Discourseのものよりはるかに限定的ですが）に精通していました。そのため、最初のメンバーが現れる前に、グループをかなりうまく設定することができました。
ここでは、参加する準備ができているアクティブなメンバーの潜在的な層がいますが、プラットフォームとその可能性について十分に精通していないため、「ローンチ」（たとえソフトなものであっても）の前に、私が望むようにすべてを準備することは、今のエネルギーレベルで無理なくこなせる期間内では難しいと感じています。
頭の中でアイデアを巡らせた結果、いくつかの可能なシナリオを持っています。私は目の前で展開することに反応するのが得意であり、事前にすべてを計画しようとするよりも、エネルギー的にずっと楽だということを知っています（こんにちは、ADHD）。Discourseは既製の優れた機能が多数備わっているので、おそらく、混乱が生じることはもちろん承知の上で、標準設定のままで信頼を置いて始めるべきかもしれません。しかし、私は一人ではないでしょう。この移行のパイオニアとなるであろう既存のコミュニティの一部が必ず現れるはずです。
すでに機能の確認、決定すべきことの特定、カテゴリーのアイデアの試行、どの情報をチャンネルやトピックに入れるべきかの評価に多くの時間を費やしたので、実際の活動が始まれば、進むべき道筋が明らかになるかもしれません。
既存のコミュニティを移行する際に、このようなアプローチをとった人はいますか？
もしこの方法をとるなら、私が始めるのは以下の通りです。
特にタグ付けに関しては、かなり緩やかに設定を始めるつもりです。ユーザーにトピックにタグを付けるよう奨励することを目指します。コミュニティがDiscourseで成長するにつれて構造化に役立つタグのコレクションはすでに特定しており、それらをすぐに利用可能にし、他に何が自然に現れるかを見ていきます。
時が来たら、メインカテゴリー内にサブカテゴリー（悲嘆サポート用、中古資料用など）を作成し始めます。そして、時間が経つにつれて、どれが理にかなっているか、また、いつか正式なカテゴリーに昇格させる必要があるものがあるかどうかを見ていきます。メンバーの「ジャーニー」をより細かく制御するためのアイデア、例えば「猫ファイル」や投薬アドバイスを求めるための前提条件などは、後で導入できます。
Facebookのメッセンジャーのバックチャンネルは、Discourseでそのまま複製でき、「テスト」として関連するカテゴリーやグループメッセージを作成できます。
面白いことに、今日存在するコミュニティ全体がこのようにして成長したのです。私は基本的なもの、いくつかのルールから始め、それが進化し成長するにつれて、物事を導入していきました。
ですから、この移行を進める上でも、これが進め方なのかもしれません。
この「管理者の暗黒時代」の瞬間に、皆さんの考え、洞察、経験をいただけると幸いです🫣
ほとんどの人にはサブドメインが推奨されます。メインドメインは、紹介資料やフォーラム、Facebookページなどへのリンクを掲載するランディングページのために確保しておくと良いかもしれません。
Discobotが述べているように：
Discourseは、メインドメイン（例：
example.com）またはサブドメイン（例：forum.example.com）にインストールできます。公式のインストールガイドでは、明確さと分離のためにサブドメインの使用を推奨していますが、Discourseをメインドメインで直接実行することも可能です。多くのユーザーがメインドメインでDiscourseを正常にデプロイしていますが、SSL設定、メール配信、DNS設定などで問題に直面するユーザーもいます。
一般的なサブドメインには、「forum」、「support」、「community」、そして時には「ask」などがあります。
[quote=“ToddZ, post:55, topic:390619”]メインドメインは、紹介資料やフォーラム、Facebookページへのリンクがあるランディングページのために予約しておくことをお勧めします。
[/quote]
メインドメインはすでに存在します: https://diabete-felin.com – ブログと静的コンテンツで、ドキュメントの一部を複製していますが、私の計画はドキュメントをDiscourseに統合することです。だからこそ、メインドメインにDiscourseを設置することに惹かれています。ただし、ログインしているユーザーとログインしていないユーザーの両方にブログのようなものをメインページに表示できることが前提です。しかし、まだ頭の中でははっきりしていません。
[quote=“ToddZ, post:55, topic:390619”]一般的なサブドメインには、「forum」、「support」、「community」、そして時には「ask」があります。
[/quote]
私たちはフランス語話者でFacebookへの依存度が高いため、語彙の選択が変わってきます。調査をしましたが、これが浮上したものの、メインドメインを使用するという考えとまだ揺れ動いています。「ブログ」カテゴリを設定し、それをスタイリングして、「ぼんやりとしたビジョン」のランディングページに似たものを生成できるかどうか試してみるべきかもしれません。
通常の過剰設計と最適化の罠に陥るのではなく、もっと違うアプローチをすべきではないかと考えています…
あなたは何か重要な点に気づいているかもしれませんね
既存のコミュニティを移行するために、[段階的で有機的な]アプローチを取った人はいますか？
はい、私は、ぎこちないWordPressフォーラムから、その構造を複製し、そこから物事を移行しました。Discourseは一度にすべてを取り込むには多すぎるかもしれませんが、段階的に構築していくのはかなり実行可能で楽しいものでした。
それはいつ頃ですか？コミュニティの構造と組織は時間の経過とともに進化しましたか？例をいくつか共有していただけませんか？
カスタムのホームページ/ランディングページを作成することについては、いくつかのトピックがありますが、アプローチによってはかなり技術的です。その道を行くのであれば、最もアクセスしやすいオプションはDiscourse-home-page Plugin または Landing Pages Plugin でしょう。
しかし、メインドメインを分離しておけば、そこに何を配置するかについて常に完全な柔軟性があります。（私はcarrd.coでランディングページを選択しましたが、これは好きなようにスタイルを設定し、変更できます。）
もちろんです！数年経ちましたね。宣伝になってしまいますが… forum.TASAT.org は、いくつかの導入資料と、「Challenges（課題）」と「Wild Speculations（荒唐無稽な憶測）」という2つのカテゴリのサイエンス・フィクションに関するQ&AでWordPressで始まりました。私はそれらと既存のコンテンツを移行し、トピックに適切にタグを付けました。
すぐに、自分用と数人のダミーアカウント用（TL1ユーザー1人とモデレーター1人、それぞれの視点を体験するため）にグループとプライベートカテゴリを作成しました。
基本操作に慣れた後、公開しました。それ以降のいくつかの展開です。
Discourse に関してはすべて非常にうまくいきました。より大きな課題は、オーディエンスを広げることでした。あなたにはその問題はないようですね 
