HAWK
(Hawk)
1
「コミュニティが軌道に乗るには14日では短すぎる」という理由でトライアル期間の延長を求めるサポートチケットが届くたびに、私の心の一部が死んでいくのを感じます。
10年前、コミュニティビルダーたちは、コミュニティが軌道に乗るには6ヶ月でも十分ではないかもしれないと認識していましたが、それを受け入れていました。彼らは、コミュニティ構築は長期的なゲームであり、プレイはローンチのはるか前に始まることを理解していました。ソーシャルメディアとDiscordが支配する今日の世界では、人々はフォロワーを増やすことを優先して、真のコミュニティ構築の技術を失いつつあります。聴衆をコミュニティと誤認することは、オンラインコミュニティの根底にある社会システムの複雑さを考慮に入れていません。
真剣なコミュニティビルダーは、コミュニティはエコシステムであり、適応戦略を必要とするライフサイクルを持っていることを知っています。
そのライフサイクルは、無料プラットフォームのトライアル段階よりずっと前に始まるInception(創成期)から、最終的に長続きする健全なコミュニティに起こるMitosis(分裂期)まで続きます。
すべてのコミュニティがこの最終段階に到達するわけではありませんが、私が最初に参加し、後に管理することになったコミュニティであるThe SitePoint Forumsはその例です。私がそこを離れてから10年以上経ちますが、今日でも活況を呈しているそのコミュニティとの間に、深く永続的なつながりがあります。新しいキャリアに転身するために必要なスキルを学ぶためのサポートを提供してくれただけでなく、永続的な個人的な友情、強力なプロフェッショナルネットワーク、そして長年の顧客も提供してくれました。
そのレガシーはどのように作られるのでしょうか?
これは、https://blog.discourse.org/2025/11/the-community-lifecycle-from-launch-to-legacy の元のエントリの付随するディスカッション トピックです。
「いいね!」 19
manuel
(Manuel Kostka)
3
これを改善するためには、コミュニティプラットフォームは、コミュニティのライフサイクルの避けられない第5段階である「アーカイブ」をより良くサポートする必要があります。現在、コミュニティを動的なプラットフォームから、メンテナンスやサーバー費用をかけずにオンラインで永続できる静的なアーカイブに移行するための良い選択肢がありません。
私も、オンラインで共通の目標を推進するために人々を結びつける素晴らしい例であったコミュニティのメンバー兼管理者として、この経験をしました。それをウェブ上のアーカイブや参考資料として保存できれば素晴らしいのですが、実際には実装が困難です。
Discourseがこの分野をリードし、コミュニティのライフサイクル全体を通じてサポートし、活発なエンゲージメントが終了した後でも、形成されたコミュニティを尊重し保存するウェブを構築するのを支援してくれると素晴らしいでしょう。
「いいね!」 12
フォーラムのコンテンツをアーカイブする標準を開発するために、インターネットアーカイブと協力していただけるでしょうか。フォーラムソフトウェアはそれぞれ異なりますが、明らかに共通する点もあります。他のフォーラムソフトウェアからの移行に関するあなたの経験は役立つでしょう。
「いいね!」 5
eisammy
(Sammy)
5
私は毎日、ユーザーがコンテンツを削除できるようにしながら、編集履歴を保持するという方法で、インスタンス全体をWayback Machineに保存しています。これは良い方法だといつも言っています。いつか続けることができなくなるかもしれないので、しばらくの間、できる限りのことを保存しています。スタッフにもこれらのことを教えていますが、これには長い時間がかかります。
HAWK
(Hawk)
6
もう少し詳しく説明していただけますか?現在、ホスティングでサイトを永続的に読み取り専用モードでアーカイブするオプションを提供していますが、継続的なコストがかかるため、無料では提供できません。
「いいね!」 4
manuel
(Manuel Kostka)
7
サイトマネージャーにとって、読み取り専用モードは積極的にモデレーションする必要がないことを意味しますが、アーカイブとは異なります。インタラクションはオフになりますが、技術的には他のすべては同じままです。インスタンスをホストし、最新の状態に保ち、同じサーバーを維持する必要があります。
真のアーカイブとは、動的なアプリケーションとデータベースのセットアップから静的なHTMLに移行することです。コミュニティスクリプトがいくつかありますが、実際に試してみると、それがどれほど複雑であるかがわかりました。個々のコミュニティがゼロから解決するには難しすぎると考えます。UIの表現とデータプライバシーの処理にも対応する標準的な移行ソリューションを提供することは、コミュニティをより良く保存するために大いに役立つでしょう。
概念的な側面もあります。コミュニティプラットフォームが最初からライフサイクル全体をサポートしていれば、現在注目していないような方法でも、全体的により良いシステムにつながる可能性があります。通常の製品設計では、製品の廃止を計画することは、優れた設計の一部にすぎません。
小規模なスケールでは、グループが良い例であり、同様のユースケースです。現在、サイトは休眠状態または放棄されたグループで終わることがよくありますが、グループは痕跡もなく消えてしまうこともあります。グループ設定の初期段階で、予想される寿命とサンセット計画があれば、サイトマネージャーがグループ全体をより意図的かつ組織的にサポートできるようになります。
「いいね!」 10
simon
9
Discourseから標準的なMarkdownコンバーターへの移行は、多くの柔軟性をもたらすでしょう。カテゴリ、タグ、作成者、可視性などのメタデータは、フロントマターとして保存できます。カスタムまたは既存の静的サイトジェネレーターでMarkdownファイルをHTMLに変換できます。Markdownをサポートするノートアプリでファイルをローカルに読み取ることもできます。Discourseは、アーカイブされたサイトをフォーラムに再変換できるように、MarkdownからDiscourseへの移行スクリプトを提供することもできます。
Markdownアプローチにより、DiscourseはフォーラムのコンテンツがDiscourseアプリケーションとは独立しているという考えを推進できます。これにより、Discourseで作成された投稿が100年後に読まれることを想像できるようになります。
オンラインイベントのために人々が集まり、自然な始まりと終わりがある場合があります。たとえば、オンラインセミナーの準備とフォローアップです。Discourseはこれに適したツールになる可能性があります。ライフサイクルを明示し、コンテンツのアーカイブを提供することで、たとえば2か月で5つのトピックと100の投稿を生成したフォーラムは、失敗ではなく成功と見なされる可能性があります。明示的な終了日は、一部の人々がサインアップしてディスカッションに参加する意欲を高める可能性もあると推測します。
「いいね!」 7