新しいコミュニティに不可欠なコンテンツとは?

新しいコミュニティを開始するために不可欠なコンテンツは何だと思いますか?

Discourseには、アバウトページの説明などを促すセットアップウィザードがありますが、その後はサイト訪問者が体験するコンテンツを作成するのはあなた次第です。

私にとって、このステップはプロジェクトの妨げになる可能性があります。誰もライブの空のサイトを立ち上げたくないからです。 :sweat_smile:

そのプロセスでの障害を乗り越えるために、コンテンツリストを作成しているので、新しいサイトを設定する際に項目をチェックできます。そこであなたの知恵が必要になります! :star_struck:

私が始めるのに役立つコンテンツの短いリストを以下に示します。アイデア(およびリンクされたサンプル)で応答してください。そうすれば、コミュニティの訪問者を支援するためのより完全なリストを開発できます。:slight_smile:


  • セットアップウィザードで可能な限り多くの説明を入力する
  • サイト全体の「Discourseへようこそ」メッセージを編集し、#site-feedbackへのリンクを含める
  • Understanding Discourse for new users をコピーし、必要に応じて編集する
  • Site feedback のカテゴリ説明を編集し、ユーザーがヘルプのために新しいトピックを作成することを奨励し、他のメインカテゴリへのリンクを含める
  • Configuring how users can create and send invites for others to join your community をコピーし、モデレーター/最初のユーザー向けに必要に応じて編集する
  • 最初のユーザーを招待する! :tada:
「いいね!」 13

コンテンツというよりは、「一部の人々」といったところでしょうか。インスタンスをセットアップして最初に気づいたのは、モデレーターや最初のユーザーさえもいないことでした:sweat_smile:
/wizard/steps/invites

「いいね!」 4

チェックリストに含めるのに最適な手順(または2つ)ですね!

セットアップウィザードでは常にモデレーターの招待を求められますが、その時点では招待しません。少なくとも、何をしているのかについてのガイダンスを提供したいのです。そうしないと、彼らも真っ白なサイトに直面することになりますからね。:slight_smile:

ユーザーについては、通常、コアグループを招待し、招待機能の使い方を教えるので、これも私のリストに追加します!

コミュニティにモデレーターを招待するのはいつですか?真っ先に?

「いいね!」 3

面白いトピックですね!

私はまずチームから始めることを好みます。そうすれば、そこにいるスタッフが確立され、ユーザーを招待できるようになります。

このブログ記事も、始めたばかりの頃に役立ちました。

「いいね!」 6

役立つかもしれませんが、Discourseが複雑すぎるように見える可能性があります。新しいサイトにコピーする必要がある場合は、https://meta.discourse.org/t/discotoc-automatic-table-of-contents/111143のテーマコンポーネントをインストールし、トピックに目次を追加してください。

「いいね!」 5

必要になったときです。それより早くはありません。私のフォーラムはそれほど忙しくなく、モデレーターは必要ありません。接続されているFacebookグループも同様です。メンバーは25,000人で、非常に活発ですが、追加の手は必要ありません。

「いいね!」 2

私が常に持っているのは、Discourse カテゴリです。ここでは、ハウツーガイド、公式ガイドへのリンクを保存し、ユーザーがフォーラムに関するフィードバックを提供したり、ヘルプを求めたりするためのポイントを提供します。

さらに、「ベストプラクティス」トピックがあり、スタックオーバーフローのルールに基づいた、良い質問の仕方などが含まれています。

「いいね!」 5

Yeah, we might break that down into smaller docs, and have that topic serve as an index; then each sub-topic could be copied and pasted as needed… not the most straightforward process, but would be helpful to allow folks to generate their own doc(s) for their community. :thinking:

Definitely don’t want every Discourse community to appear as complicated as what it is capable of. :slight_smile:

Here’s a really great example of a Discourse community using the FAQ topic to explain how it works for their users:

https://community.namati.org/t/faq-frequently-asked-questions/1467

Good idea, I updated the info box there:

ええ、それをより小さなドキュメントに分割し、そのトピックをインデックスとして機能させ、各サブトピックを必要に応じてコピー&ペーストできるようにするかもしれません…最も簡単なプロセスではありませんが、コミュニティが独自のドキュメントを生成できるようにするのに役立つでしょう。 :thinking:

確かに、すべての Discourse コミュニティがその能力と同じくらい複雑に見えるようにはしたくありません。:slight_smile:

ここに、FAQトピックを使用してユーザーに仕組みを説明している Discourse コミュニティの非常に優れた例があります。

https://community.namati.org/t/faq-frequently-asked-questions/1467

良いアイデアですね。そこの情報ボックスを更新しました。

「いいね!」 2

理想的な世界では、そのようなドキュメントは「ヘルプ」サイドバーのDiscourseインスタンスで直接利用できます。Slackが行っていることに似ています。理想的ではない現実の世界では、サイト上のトピックにドキュメントをコピーすることが理にかなっています。

「いいね!」 3

これは私がコミュニティのために行ったことです。たとえば、「動画を埋め込むにはどうすればよいですか?」と検索すると、それだけをカバーするトピックが表示され、それ以上のものはありません。サイトで動画が許可されていない場合は、そのようなトピックを省略できます。さらに、大きなガイドに含まれるトピックの混合ではなく、その特定のトピックに関連するドキュメントのみを記録することで、問題が発生した場合にそのトピックに返信できます。

これの2番目の利点は、他のDiscourseトピックのワンボクシングを活用して、複数の大きなガイドでクロスリファレンスできることです。

これは、トピックが個別のトピックに分割されていますが、「メイン」ガイドの下に統合されているセーリングガイドの例です。この場合、SBF SEEは1種類のライセンスのトピックです。SBF Binnenは別のトピック(ここでは表示されていません)で、まったく同じナビゲーション情報を持っています。そのため、1つのナビゲーショントピックを維持し、両方のガイドにリンクします。

残念ながら、すべてのものがワンボクシングでうまくレンダリングされるわけではありませんが、それでもトピックを組み合わせて、同じ情報を参照する必要があるすべてのトピックを更新する単一の編集ポイントを作成するための優れた方法です。

完全に同意します。サイドバーよりもDiscourseカテゴリがある方が良いと思います(ただし、サイドバーでアクセスできる可能性があります)。なぜなら、それはユーザーがコミュニティのセットアップに関する問題を提起することを奨励し、管理者がトピックをコミュニティによりよく一致するように変更することを奨励するからです。たとえば、デフォルトの画像をプラットフォームに固有の画像に置き換えるなどです。

「いいね!」 2

これはニッチによるでしょうが、一般的にほとんどのユーザーはサイドバーを見ることはありません。少なくともヨーロッパでは。北欧では、普通の一般市民のほとんどはもはやデスクトップ/ラップトップを所有しておらず、携帯電話を使用しています。

まったく別の話題ですが、ほとんどのサイトは小さな画面のためにレイアウトとUXを設計し、その後、デザイナー/コーダーに余った時間があれば、デスクトップ/タブレットに労力を費やすべきです。

「いいね!」 2