Discourseはコミュニティプラットフォームとして、なぜもっと頻繁に推奨されないのか?

言及されている競合他社については何も知りませんが、Discourse のセットアップで気づいたことは、サイトにかなりの量のコンテンツがある場合に最も効果的で、他の人に示すのが最も簡単なということです。そのため、オンボーディングが難しくなります。なぜなら、私のように「実際の」コミュニティフォーラムの潜在的なメリットを知っている人が、他の人にそれがどのようなものかを示すためにより多くのことを行う必要があるからです。

同僚に Discourse の使用を説得しようとしたとき、私たちが構築したいコミュニティのような他のコミュニティを見つけるのに苦労しました。それは、私たちの用途が主に内部的であること、そして既存のユーザーが非常にニッチであることも一因です。私が以前に見つけた最良の例は Stan フォーラムでしたが、それは同僚と共有するには技術的すぎました。Discourse がどのように使用されているかのより良い例を提供することは役立ちます(単なるリンクではなく…実際にレビューし、Discourse が優れている理由を示す優れたスレッドへのディープリンクを提供してください)。

別の選択肢としては、非常に大きなマスマーケットコミュニティをいくつか引き抜き、損失を出してでも安価な取引を提供することが考えられます。たとえば、私たちの中の多くの人が Stack Exchange ソフトウェアに慣れていたため、それを購入しかけました(ただし、qa はすべてのコンテンツの形式としてあまり適していませんでした)。

注意点として、meta.discourse は、オープンソース/コミュニティのオタク以外(彼らにとっては非常に魅力的ですが)にとっては、あなたのための優れた宣伝にはなりません。それは、一般の人々にとって魅力的にはほど遠い、あまりにも詳細で些細なことです。

しかし、それは製品自体ではありません - Discourse は素晴らしいです!

「いいね!」 1

metaは主にこの目的のために作られたものではなく、製品サポートサイトです。そのため、製品サイトであるhttps://www.discourse.org/があります。

「いいね!」 2

その点については try.discourse.org でさらに改善できると思いますが。ドキュメントに関する別のトピックで、すでに「作業中」カードを数分前に引き出しました(そして、すぐに2回使用するとストレス頭痛が起こります:slight_smile:)。しかし、多くの異なる機能の例を備えたインタラクティブな「説明」サイトがあれば、これに大いに役立つと思います。

「いいね!」 5

ディスコースの可能性には間違いなく関心があり、私がグループ、サークル、haaartlandなどを管理したことのあるプラットフォームであるmightyについても認識しています。

何らかの理由で、ディスコースだけでなく他のプラットフォームについても、意思決定に役立つと思われる情報をすべて見つけるのに苦労しています。

JD、私がConwayの法則を強く支持していることをご存知でしょう。
ディスコースはその現れを示しています。たとえば、コーディングホラーズが署名付き投稿を嫌うことは、他のフォーラムやここでのデフォルトガイドに現れています。トピックに複数の返信を送信することや、返信を1つの投稿に集約しないことに関するメッセージ…

より深いレベルでは、開発チームの哲学的または文化的な連携がソフトウェアを決定します。たとえば、mightyはすべてのコミュニティがサブになるように自分たちを最上位に位置付け、mightyアプリを使用すると、ユーザーは関連性/興味のあるコミュニティを検索できます。

ほとんどの人は複数のプラットフォームに関する同等の知識を持っていないため、十分に情報に基づいた選択ができないことも認識しておいてください。そのため、技術的な考慮事項は広告によって緩和され、ほとんどの人は「光沢のあるウェブサイト」を持っています。多くの人は、ソフトウェアをインストールして再構築せずにオン/オフできるオプションを備えています。そのため、ディスコースがテーマやコンポーネントに向かうことは、開発者、技術者、ソフトウェア管理者にアピールしますが、料金を支払って使用を開始する商業組織や、完全なPayPal、Stripe、グローバル税などの統合を備えたペイウォールの背後にコミュニティをゲートしたい人にはアピールしません…

それは単に「馬に合った馬」というだけではありませんが、それは重要ですが十分ではありません。

右 - しかし、このようなものを評価したり、誰かに可能性をデモしたりする際に、まず最初に行いたいのは、セールストークを読むことではなく、実際に使われているのを見ることです。(少なくとも私はそうです)。Metaがそうあるべきだと言っているわけではありません。ただ、そのニッチを満たしていないだけです。

「いいね!」 2

はい、それはわかります。おそらく、WhatsAppやFacebookのような非常に人気のある中央集権的なプラットフォームではないことの副産物でしょう。そこでは、すでにかなりの個人的な使用経験があるかもしれません。しかし、@JammyDodgerのように、デモサイトがあります…

「いいね!」 1

しかし、デモサイトはそれが趣味のプロジェクトのように見せています… phpbbのようなものです。あなたは「機能」を見ることができます。それらのすべての機能が生み出す価値を示していません。

Discourseがコミュニティをどのように強化するかを示す、より良い例をいくつか提供するために、アクティブなRedditやFBグループのいくつかを誘致しようとすることは機能するのではないかと思いますか?いくつかの大きなフォーラムの主要なモッドに連絡して、利益を得るようにすることは、それほど費用はかからないでしょう。

参考までに、同僚に示すために見つけた最良の例はdrownedinsoundでしたが、それはおそらく私のボスと部署の他の数人が新しい音楽に興味があるからかもしれません。子育て/スポーツ/映画のような他の幅広い関心のあるトピックをターゲットにしたり、例を入手したりすることはどうでしょうか?

「いいね!」 2

Discourseディレクトリサイトを誰かが始めるべきでしょうか?(存在するかもしれません?)

Googleで検索すると、例えば次のような検索結果になります。

"Discourse <いくつかの件名キーワード>"

少なくとも私の経験では、Discourseベースのサイトが見つかりません。

それは興味深い問題ですね…

…おそらく、CDCKからのプレッシャーが低いことと、サイトを自由にブランディングできる柔軟性によるものの一部でしょう。

皆さんに一般的な質問です:あなたのサイトには説明文に「Discourse」という言葉が含まれていますか?

「いいね!」 2

私も同じ経験をしています。また、Discourseの多くのカスタマイズは(私の意見では)かなり悪く、人々が試みるCSSやその他のレイアウトの変更は、実際にはユーザーにとっての体験を悪化させ、サイトを例として使用する際にも悪化させます。

ブランド化したいことは理解できますが、ここには明らかに緊張関係があります…ほとんどの人は、実際に物事を改善するスキルや専門知識を持っていません。デフォルトのDiscourse UIは優れています — 特にパワーユーザーにとっては。

「いいね!」 2

多くの人にとって、これは趣味であり学習の旅でもあります。これもまた軽視すべきではありません。

自身のDiscourseサイトをデプロイすることで人々が習得するIT知識は非常に多く、これは間違いなく非常に肯定的なこととして強調すべきです。

「いいね!」 3

多すぎると思います。Dockerインストールはありますが、設定はもっと簡単になるはずです。私は様々なサイドプロジェクトでDevOpsの経験がありますが、セルフホスティングの経験から、積極的に非推奨にされていると感じました。メールの設定は難しく、設定ファイルの編集が必要でした。プラグインも同様です。これらすべてを管理UIに含めることができます。注 - 苦情を言っているわけではありません。ホスティングサービスを利用してもらうために、あえて難しくしている部分があることは理解しています。ただ、セルフホスティングでの洗練されていない体験は、これが「推奨」されるオプションではなく、廃止されるかもしれないと心配になりました。

ホスティングを希望しない人のために、VPSプロバイダーへの紹介で収益を得ることは可能でしょうか?そのプロバイダーは、SMTPサービスを提供し、1クリックインストーラーをセットアップできるものです。これにより、参入障壁が大幅に下がりますが、ホスティングサービスの売上を食ってしまうかもしれません。

「いいね!」 3

これはCDCKの戦略の一部ではないと思います。

むしろ、彼らが(コミュニティと共に)支援するために、できる限りのことをしているように見えます。

CDCKにとってのメリットは、提供されるテストの目(テスト参加者)の多さと、コードや機能リクエストによる追加の貢献です。

「難しい」とはどういう部分でしょうか?

自分でプラットフォームをホストするために必要な最低限のコミットメントと労力には限界があると思います。また、すべてがボタン一つで済むとしたら、彼らはどうやって自分のウェブサイトをサポートするのでしょうか?明らかにCDCKはその責任を分離しなければなりません。個人的な関与や、契約による他のSME(Subject Matter Expert)の直接的な関与によって、長期的なサポートに必要な知識を持っているか、または獲得する意欲があることを期待するのは合理的です。

数回経験すれば、完全に新規で、100%独立した、完全に所有された、標準仕様のサイトを20分以内にセットアップできます。ドメインの購入も含めてです!これは驚異的ではありませんか?

個人的には、「プラットフォームの例を提示する」というあなたの意見の方が、より公平なコメントだと感じています。

「いいね!」 4

Discourseフォーラムのデフォルトの公開文字列である「This is a Civilized Place for Public Discussion」のような文を検索していたメタの誰かを思い出します。他の言語でも機能し、他の言語でも検索できます。

「いいね!」 4

それを再試行しましたが、私のサイトには効果がないようです…あなたの場合は異なるかもしれません…

Discourseの問題と、Discourseでは解決できない問題を注意深く区別する必要があると思います。メールの設定は面倒ですが、フォーラムでメールを送信する長年の経験から、最大の課題はフォーラムソフトウェアではなくメール自体にあることを知っています。悪用を防ぐために非常に厳しく制限されているため、送信メール環境の設定にかかる時間と労力は、通常、Discourseのメール設定に必要なわずかな時間をはるかに超えます。

DNS、SPF、DKIM、送信制限、フィルタリング、ブラックリスト回避を含むメール用のドメイン設定が本当の苦痛であり、メール送信のためにDiscourseで必要なことはほんのわずかです。ドメイン関連の作業ができれば、Discourseの設定はそれに比べて簡単です。あるいは、Discourseの設定部分を扱えないのであれば、Discourse以外のメール設定で悪夢を見る可能性が高いでしょう。

「いいね!」 5

mmdv - 私にはうまくいきました。私は、私の特定のサイトを絞り込むために、さらに1つのかなり一般的な単語(weather)を追加しました。そしてリストのトップに来ました。したがって、文字列を検索しただけなら、最終的にはリストのどこかで見つけることができたと仮定します。

「いいね!」 2

全く同感です。電子メールが最も複雑な部分です。いくつかのサイトをセットアップしたら、既存の電子メールインフラストラクチャを活用することで、物事がずっと簡単になります(もちろん、ドメインセットアップのハードルを越える必要はありますが)。

「いいね!」 1

いいえ。そして、これからも決して含まれることはありません。申し訳ありませんが、私のフォーラムはCDCKの広告ではありません。WordPressも同様です。そして、特定のエンジンを使用しているコミュニティ/フォーラムを探している人は誰もいません。

TINSTAFL(There Is No Such Thing As A Free Lunch)は知っていますが、私のユーザーは皆、私がDiscourseを使用していることを知っているか、知るべきです。私のWordPressは全く別の話です。

他に探すべき技術的な詳細があるはずです。私たち皆が、フォーラムがDiscourseで構築されているかWordPressで構築されているかをすぐに知るのと同じように。CDCKは私が彼らの製品を使用していることを知っています😏

「いいね!」 2

批判的に聞こえたならごめんなさい。実際には「難しい」とは思いませんが、ドキュメントがこのメタサイトに散らばっており、以前にRailsアプリをインストールしたことがない場合は、かなりの前提知識が必要になるかもしれません。私は以前に多くのPython(特にDjango)を扱ってきましたが、設定ファイルを編集して再コンパイルすることが、実行時設定になりうるものとしては奇妙なプロセスだと思いました。

結局のところ、あまり好ましくない選択肢のように感じましたが、無料だったので受け入れました。

これは、ここで人々がDiscourseのUIを評価する問題に少し似ています。私たちは皆それを気に入っており、慣れています。しかし、昨年私の学生が初めてそれを使ったのを見るのは興味深いことでした…彼らは常にそれを簡単だとは感じず、一部(すべてではない)はそれを「冗長」で混乱を招くと表現しました。ほとんどは最終的にそれを気に入りましたが、オンボーディングは、この種のコミュニティに慣れている人々により適していました。

とにかく、新しいDigitalOceanドロップレットへのインストールのプロセスに関するコミュニティドキュメントの作成など、喜んでお手伝いします。また、メールでのセットアップのベストプラクティスに関するガイドがあると役立つと思います。多くのインバウンドプロセスは複雑で、あまり文書化されていません。良いデフォルト設定を提案することが理にかなっています。

「いいね!」 6

メールが面倒である(多くの場合、正当な理由がある)というのは本当ですが、私たちが「推奨されるパス」(例:「sendgridを使用するだけ」または「SESをこのように設定する」)のガイドを提供できないほど難しいわけではありません。

私にとっては、MS/365がレガシー認証の使用を本当に望んでいないという事実によって、問題が複雑になりました。これは他の組織にとっても問題である可能性が高いと思いますが、確信はありません。(ちなみに、レガシー認証を有効にしたままにするために特別な許可を得る必要があり、ポリシー変更一つで再びすべてが停止するのではないかと心配しています。そして、私は大規模な組織に所属しており、1500人という(比較的)小規模なグループのためにサイトを運営しているため、常に優先されるわけではありません。)

同様に、365でのSSOの設定は、私の記憶ではあまりよく文書化されておらず、まだ取り組んでいませんが、本当に必要としています。次に引き継ぐ人のために、思い切ってガイドを書くべきです。

「いいね!」 2