Metaでのカテゴリ整理方法の更新

Meta のテーマと構造の更新の一環として、カテゴリの構成を変更する予定です。

これまでにいくつかの異なるアイデアを検討してきましたが、コミュニティからのフィードバックを得ながら、さらなる改訂を経る必要があると考えています。現在最も有力視しているアイデアを以下に示します。

基本的な考え方は、関連するカテゴリを少数のトップレベルカテゴリにグループ化し、それらのカテゴリはデフォルトで新規ユーザーのサイドバーに表示されるようにすることです。

  • ニュースとイベント (News and Events)
  • サポート (Support)
  • コミュニティの成功 (Community Success)
  • 貢献 (Contribute)
  • カスタマイズ (Customization)
  • ドキュメント (Documentation)
  • コミュニティウィキ (Community wiki)
  • マーケットプレイス (Marketplace)

サポートは引き続き最もアクティブなカテゴリの 1 つになると予想しており、他のサポート関連のカテゴリをその下にグループ化することで、選択の麻痺を減らせると考えています。ここにはさらに洗練させるべき点があるでしょう(SSO はカテゴリにすべきかタグにすべきか?インストールとホスティングの実際の違いは何か?これらは単一のセルフホスティングサブカテゴリに折りたたむべきか?)。これらの疑問は今後検討していきますが、全体的な形としては、すべてのサポートトピックを 1 か所にまとめることです。

コミュニティの成功は、既存のコミュニティカテゴリを基盤として、さらに投資したいと考えているカテゴリです。ここは、成功した Discourse コミュニティの運営に関わるすべての人々が、技術的なサポートではなく、成功するコミュニティを構築するために必要な厄介なソフトな部分について、互いにサポートし合える場所になると考えています。ここでも基盤となる構造を再構築する可能性がありますが、当面は既存のコミュニティとデータおよびレポートのカテゴリが主要な柱になると考えています。

貢献は、製品自体とこのコミュニティを改善する方法についての議論の中心となるカテゴリとして構想しています。

カスタマイズは、プラグイン、テーマ、コンポーネント、その他の拡張機能を使用して Discourse を拡張するすべてのトピックを見つける場所になります。

より詳しく確認したい場合は、現在ステージングサイトでこの構造を実装しており、確認することができます。

ステージングサイトへのアクセス方法
  1. https://meta-redesign-2026.discourse.group/ にアクセスします。
  2. HTTP 基本認証のために、このユーザー名とパスワードを入力します。
    • ユーザー: meta2026bsbx
    • パスワード: Q0U1ppbVbd2MVttuYOl+M8SYEOUqGLGjzl5sr1C9XwE=
  3. Meta のメールアドレス/ユーザー名とパスワードを入力します。
    (ステージングサイトは他のログイン方法をサポートしていません)。

確認していただけましたら、こちらでご意見をお聞かせください。

「いいね!」 5

self-hosting のようなカテゴリがあれば、何がそこに属するのかが明確になると思います。それでもまだ良い名前ではありませんが、#installation よりはましです。#installation は、Discourse が一度も動作したことがないかのような印象を与えます。私も初めて自分のトピックがそこに移動されたときにはかなり混乱しました。もしかしたら、「バックエンド」はどうでしょうか?

問題を引き起こしたり、問題を目撃したりするためにシェルにアクセスする場合は、そこに移動します。Discourse が「動作して」いて、それが UX やテーマなどに関係する場合は、サポートに移動します。

「いいね!」 7

賛成です。

さらに進んで、この新しいセルフホスティングカテゴリに InstallationInstallation > Hosting を統合すべきだと思います。

残りの部分がどのように決まるかにかかわらず、これは実行できると思います。上記のスケッチで示した方向性で行くなら、この新しいカテゴリはSupportのサブカテゴリになります。

現在のフラットモデルにより近い形で維持するなら、トップレベルのカテゴリになります。

「いいね!」 4

以下の通り変更を行い、新しいトップレベルの #support:self-hosting カテゴリを作成しました。

  • 以前 Installation > Hosting にあったすべてのトピックに #hosting タグを付与しました
  • Installation > Hosting からのすべてのトピックを、かつての Installation にマージしました
  • Installation#support:self-hosting にリネームしました

「Self-hosting support」よりも「Self-hosting」の方が良いかもしれません(特に Support の下に移動する場合など)。ただし、まずは第一歩として、今回は「support」という単語を含んだ、やや冗長な表現を選びました。

「いいね!」 3

ご参考までに、「セルフホストサポート」は、それがセルフホスターがすべてのサポートを受けるための特定の分野であるという印象を与えたため、以前は避けていました。最初の印象としてそれを持ちたくありませんでした。

また、「ドキュメント」カテゴリと非常によく似ており、簡素化を目指す場合、重複は避けたいところです。

「設定」も除外されました。なぜなら、すべての機能/設定/プラグインなどは「設定」が必要だからであり、十分な説明がなかったからです。「システム管理者」は、Discourseサイトを運営するためにどれだけ技術的になる必要があるかを強調したくなかったため、技術的すぎると見なされました。

「インストール」は曖昧だったことには同意しますが、実際にはそれほど混乱を招きませんでした。しかし、より良い名前はあるはずです… :slight_smile:

「ホスティング」については、基盤となるサービス(Digital Ocean、Mailgunなど)について話し合う場所でした。サーバー管理とは異なる明確な特徴があったと思いますし、500以上のトピックがあれば、(すでに存在していなかったとしても)会話を分割するのに十分なほどだと思います :slight_smile:

「いいね!」 8

私にとっては、以下のような内容が期待されます。

  • ホスティング: ホスト(サーバー)の選択と管理について
  • インストール: 「Discourseが存在し、管理者としてログインして操作できる」状態になるまで
  • 設定: さまざまな設定に関する詳細な部分

初心者にとっては、コアと「バンドルされたプラグイン」との区別があまり明確ではないと思います。そのため、これらは設定に含めるか、少なくとも非常に明確なポインターを示すべきだと思います。

「いいね!」 4

これらは、カテゴリとして期待するものと、タグとして期待するもので、どちらが異なるでしょうか?

そして、これらは Support カテゴリとどのように関連すると期待しますか?

「いいね!」 2

私としては、インストールとホスティングはタグとして扱っても問題ないと思います。ただ、(私のコミュニティのためにも)特定の主要なタグをカテゴリ内で「ピン留め」したり前面に出したりする方法はあるのか気になります。それらをカテゴリとしてもよいかもしれません(「ストーリーを語る」という観点で考えると)。

設定:セルフホスティング利用者向けとホスティング管理者向けでは、大きく異なるものになるでしょうか? 内容が重複しそうだという印象があり、そのため「セルフホスティング(サポート)」というカテゴリに閉じ込めるべきかどうかは迷っています。このカテゴリ名は「セルフホスティング」から変更したほうがよいかもしれませんね。むしろ Support は「一般的なサポート」といったニュアンスでしょうか? メタのほぼすべてが何らかの形でサポートに関連している不是吗?

余談ですが、Support > Migration というタグは私には少し混乱を招きます。「人を第一に考える」立場の人間として、私は直感的に「全体としての移行をどう管理すればよいのか」と考えてしまいます。しかし、そのカテゴリを見てみると、実際にはスクリプトやエクスポートなど「技術的な移行」に関する内容が中心のようです。

最近、facebook-migration について議論がありましたが、これは主に戦略や人、そして具体的な課題に関するものでした。ある意味では、Support > Migration は、移行におけるより一般的、あるいは人間的な側面を気にする人々にとって「悪意あるアトラクター(引き寄せ役)」として機能してしまうように感じます。どういうことか、お分かりいただけますでしょうか?

「いいね!」 2

アプリでこれに対するより大きなアフォーダンスを持つことは検討に値するかもしれませんが、どのように機能すべきかはわかりません。

今のところ、これは非常に有機的に起こっていると思います。特定のタグの臨界質量が特定のカテゴリに蓄積し、人々はそのパターンに気づき、それが繁栄するように奨励し始めるのです。

特定のカテゴリにタグを制限したり、特定のタググループから特定の数のタグを要求したりするための組み込み機能はありますが、これらはしばしば厳しすぎると感じます。

:+1: 同意します。設定は「一般的なサポート」(ポートの指定など、システム管理者レイヤーでの設定でない限り)と考えるべきだと思います。

ええ、私も最初にそう考えていました… 一日置いておきますが、この詳細は明日再検討します。

その通りですが、その余分な単語がどれだけ役立つかはわかりません。しかし、あなたの言いたいことはわかります。

ええ、ここに2つのカテゴリが隠れている可能性があります。提案されたネストされた構造のレンズを通してこれを見ると、おそらくこれは support/migration のようなものと dev/migration のようなものに分割されるべきでしょう。

ここではまず小さな一歩を踏み出しながら、時間をかけてそれをさらに形作っていくことができると思います。

おっしゃることはわかります。ただし、それらがドロップダウンに隠されているという事実は、目立つように表示できるサブカテゴリよりもはるかに見えにくくしています。

これは後でまたお話ししますが、サブカテゴリの乱立を避けるために、私がかなり広範囲に使用する予定のものの1つだからです(特定のカテゴリで特定のタググループから少なくとも1つのタグを要求すること)。:sweat_smile:

一部はその通りだと思いますが、別の部分は「インストール」の継続、つまりセットアップのすべてのことです。さて、Discourseをインストールしましたが、これには信じられないほどクールな機能がすべて備わっており、多くのことを制御できますが、それをコミュニティのニーズに合わせて「形作る」にはどうすればよいでしょうか?この部分は以前、私を非常に落胆させました。なぜなら、すべての設定などは文書化されていますが、a) どこから始めればよいのかを理解することと、b) コミュニティに対する「ビジョン」を設定や構成にどのように反映させるかを理解することに苦労したからです。

ですから、私が考えているのは、初期設定の道のりの周りの追加のレイヤーかもしれません。「サポート」(「一般サポート」とは改名しません。どのように認識していたかを示すために言っていました)は、「稼働中です」または「解決する必要のある特定の С問題があります」という場合のためであり、「起動の準備をするために何をすべきか」という、箱から出したばかりのインストールに関するものではないと思います。

これらすべてから言えるのは、「設定」は管理者の道のりの一部として意味をなすものであり、それは「サポート」と全く同じではないということです。

私のコミュニティとの並行例(適切な会話でそれについてニュースを伝える必要があることを思い出させます)は次のとおりです。糖尿病の猫の飼い主が診断を受け、私たちのコミュニティに参加した場合、カテゴリをどのように整理しますか?私が今決定したのは、「メンバー中心」になり、「たった今到着した、何が何だかわからない」(より丁寧なフランス語の同等語)から始め、「必要な機材を揃える」、「学習する」となり、それからコミュニティの核となる本格的な「サポート」の準備が整うということです。

Discourseについて、かつての私のようにすべてが全く初めての人としてそのように考えると、1) 自己ホストするかどうかを判断してホスティングを選択すること、2) 実際のインストールを完了すること、3) コミュニティを設計し、それをDiscourseの設定に反映させること、が間違いなくあります。そして、この場合、a) ゼロから構築している場合と b) コミュニティが存在し、それを移行したい場合とで区別をする必要があります。私のFacebook移行の課題のトピックで議論したように、セットアップのアプローチは本当に変わると思います。

そして、これが移行のものをどこに置くかという問題につながります。

どちらの物語を語りたいかによって、再び異なると言わざるを得ません。Discourseは既存のコミュニティのDiscourseへの移行を奨励し、促進したいのでしょうか、それともDiscourseでゼロから構築する人々に焦点を当てているのでしょうか?

驚くことではありませんが、私は既存の顧客の移行に焦点を当てることが理にかなっていると主張します。なぜなら、そこに巨大な未開拓の市場があると確信しているからです。

その場合、「移行」があまり深く埋もれてほしくありません。私は個人的に、それをコミュニティ管理の側面として維持したいと考えています(そして現在のコミュニティカテゴリをそのように改名します。「コミュニティ」だけでは曖昧で、当初は「Discourseコミュニティのため」という意味だと誤解しました。コミュニティの設計/構築/管理について、という意味ではありませんでした)。タグでしょうか、それともサブカテゴリでしょうか?少なくともサブカテゴリに値するかもしれません。移行スクリプトや移行に関する技術的なものは、別のトップレベルのカテゴリに入るでしょうか?

あるいは、移行自体がカテゴリであり、コミュニティの既存の側面をDiscourseにどのように適応させ、反映させるかに関する議論、移行の実際のプロセス(実装)へのアプローチ、そして「データ移行」も含まれるのかもしれません。

「いいね!」 1

待ってください。unsupported-install のように、ユーザーにトピックに #standard-install のタグを付けるよう促す方法はないでしょうか?

ただし、それをどう実現するかはまだよくわかりません。

「いいね!」 2

現在の提案では、「コミュニティ・サクセス」を最上位カテゴリとし、「コミュニティ・マネジメント」をそのサブカテゴリとして想定していますが、この点についてあなたの考えとどのように一致しますか?


典型的なジャーニーのステップについての私たちの理解を明確にするための何らかの道しるべを設けるというアイデアは気に入っています…

「いいね!」 1

この2つの違いがよくわかりません。「コミュニティ・マネジメント」に含まれないものが「コミュニティ・サクセス」に含まれるとしたら、具体的にどのような内容でしょうか?ここで#community-building に投稿した内容を考えると、それらを「コミュニティ・マネジメント」に入れるべきか「コミュニティ・サクセス」に入れるべきか迷ってしまいます。

今日は頭が回らなくなってきたので、明日か金曜日にじっくり考えさせてください。すみません!

「いいね!」 1

モックアップに表示されているサブカテゴリ以外に、コミュニティを「管理する」こと以外に、あなたが言及した他の2つの活動(設計と構築)があります。

しかし、ほとんどの人にとっては、それらすべてがまだ「管理」に含まれるのかもしれません。

クリックして移動

認証情報付きのワンクリックステージングサイト

→ ロボットがアクセスしないように隠しています。

カテゴリの再編成案は以下の通りです:

  • ニュース&イベント
    • お知らせ
    • ブログ
    • サマリー
  • コミュニティ
    • アゴラ(旧:一般)
    • サイトフィードバック
    • 称賛
    • 比較
    • コミュニティマネジメント
    • マーケットプレイス
    • ユーザーウィキ
    • 管理者ウィキ
    • 開発者ウィキ
    • システム管理者ウィキ
  • ドキュメント
    • Discourseの使い方
    • サイト管理
    • インテグレーション
    • Discourseホスティング(旧:ホスト型顧客)
    • セルフホスティング
    • Discourseへの移行
    • 開発者ガイド
    • 貢献方法
  • ヘルプ
    • インストール
    • ホスティング
    • 移行
  • インテグレート
    • WordPress
    • SSO
  • 貢献
    • バグ
    • 機能
    • 開発
    • 翻訳
    • UX
  • カスタマイズ
    • プラグイン
    • エクストラ
    • テーマ
    • テーマコンポーネント
    • データ&レポート

根拠:

  • Community Building は、他の場所で行われていないあらゆる事柄に関する議論の活発な場となり、ウィキ、一般議論(#agora)、サイトフィードバック、他ソフトウェアとの称賛や比較、コミュニティマネジメントやマーケットプレイスに関する議論など、Discourseコミュニティ全体を結びつけます。
  • #news-events は、通常のCDCKコミュニケーション用です。
  • #help はサポートを得るための場所です。
  • #integrate は特定のインテグレーションに関する議論用です。
  • Documentation は公式ナレッジベースをホストします。
  • Contribute はすべての開発プロセスをホストします。
  • #customize は、データレポートや探索を含む、各Discourseインスタンスを特別なコミュニティにするすべての要素をホストします。

新しい人が来た場合、(公式)ドキュメントか、コミュニティの議論に行くことになります…

#welcome タグを作成し、いくつかの導入トピックへのリンクを張ることを提案します。これにより、tl0からtl1への移行、雰囲気や領域の把握など、新規ユーザーを容易にナビゲートし、オンボーディングできます。

おそらくドキュメントには、The Documentation System タグである #tutorial、#explanation、#how-to、reference を目立つ位置に配置すべきでしょう。

コミュニティマネジメントは「コミュニティビルディング」と呼ぶべきかもしれません… 「コミュニティサクセス」という呼び方は、はっきりしない理由で気に入りません。

「いいね!」 3

はい、以前コミュニティで同様のことを行ったことがありますが、カテゴリーを使用する以外に、オンボーディングパスを示すための素敵で柔軟な方法だと思います。次のようなものです。
image

「いいね!」 4

この取り組みを称賛し、プロセスにご協力いただけたことに感謝します。

@stephtara さんのDiscourseの道のりを追ってきた私にとって、Metaが新しいコミュニティビルダーのための専用の場所を必要としていることは明らかです。名前は何にすべきか分かりませんが、初めてDiscourseで構築する人々のための、温かく居心地の良い場所があれば、設定オプションの過負荷による圧倒感を和らげるのに役立つでしょう。ここで助けを提供する人々は、この分野での助けの提供には余分な努力と忍耐が必要かもしれないことを理解しているでしょう。

見逃しているかもしれませんが、管理エリアの「現在」を反映したインデックスを持つ設定オプションのドキュメントカテゴリがあれば素晴らしいでしょう。Discourseは常に進化しています。ドキュメントもそれに追随して進化させるべきです。

このカテゴリ/タグの全面的な見直しに加えて、再編成に伴って既存のトピックの「新鮮な整理」が行われることを期待しています。Metaで答えを探すのに費やす時間のほとんどは、どの情報がDiscourseの現在の状態に関連し、どれが古くて適用できないのかを整理することに費やされています。私のBBSが問題の一部であることは認めますが、多くのドキュメントは整理するのが非常に困難です。スタッフがドキュメントの改善のために行ってきた、そして今も行っている作業には感謝していますが、その多く/ほとんどが見直しの必要があるようです。
そのために、ドキュメントと思われるもののほとんど、またはトピックに「レビューが必要 (Needs Review)」タグを付けることを提案します。はい、それは膨大な数のタグになりますが、レビュープロセスが完了すれば、ユーザーエクスペリエンスは大幅に向上するでしょう。私や他の人もこの努力に協力できるかもしれません。編集とタグ付けのシーケンスは、プロセスの管理に役立つ可能性があります。

私はこれをあるサイトで使用しています。

概要

レビューが必要 (Needs-Review) テキストが必要 (Needs-Text) 引用が必要 (Needs-Citation) 作業が必要 (Needs-Work) 公開準備完了 (Ready-to-Publish)

たぶん、「古くなっている (Out of Date)」タグも役立つかもしれません。

@mcwumbly この再編成を開始し、さらに私たちをプロセスに含めてくださったことに改めて感謝します。:clap:

「いいね!」 6

次のステップの計画は次のとおりです。

  • 2月23日の週
    • ここでのカテゴリ構成を最初の投稿と一致するように更新します。これまでのフィードバックに基づいて、多少の自由な変更を加えるかもしれません
    • 実際にどのように感じるかについて、ここでさらに多くの議論のフィードバックを期待します
    • フィードバックに基づいていくつかの小さな調整を行います
  • 3月2日の週
    • 全体的に順調だと感じられる場合は、引き続き調整します。または
    • 全くうまくいかないと感じる場合は元に戻します
「いいね!」 5

ここにアイデアを保管しておきます。

これは独自のトピックに値するかもしれませんが、この大きな再編成の一環として、まずはこちらでさらに議論できます。

「いいね!」 3

まず、実際にどのように感じるかを確認するために、最初の変更をここで行いました。

サイドバーのデフォルトのカテゴリも更新しましたが、まだ全員には適用していません。新しいデフォルトにサイドバーを設定して試してみたい場合は、次の手順を実行できます。

  1. サイドバーの「Categories」の隣にある編集鉛筆をクリックします
  2. モダールの右下隅にある「Reset to defaults」を選択します
  3. 必要に応じて調整します
  4. 「:Save Changes」をクリックします

今後1週間ほどで、ここでのフィードバックを共有してください。

「いいね!」 2