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

新しいトップレベルのカテゴリ「#self-hosting-support」を作成する以下の変更を行いました。

  • 以前 Installation > Hosting にあったすべてのトピックに hosting タグを付けました
  • Installation > Hosting からのすべてのトピックを、以前の Installation にマージしました
  • InstallationSelf-hosting support に名前変更しました

「Self-hosting」の方が「Self-hosting support」(特に Support の下に移動する場合)よりも良いかもしれませんが、当面の第一歩として、少し冗長で「support」という単語が含まれるものにしました。

「いいね!」 3

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

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

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

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

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

「いいね!」 8

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

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

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

「いいね!」 3

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

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

「いいね!」 2

そうですね、インストールとホスティングはタグで問題ないと思います。しかし、自分のコミュニティのためにも、特定の重要なタグをカテゴリで「固定」または「提示」する方法があるかどうか疑問に思っています。これらはカテゴリになることもあります(「ストーリーを語る」という考え方で進める場合)。

設定:セルフホストとホストされた管理者でこれは大きく異なりますか?重複する印象があるので、セルフホスティング(セルフホスティング サポート ではなく、むしろ名前を変更したい)の中にロックする必要があるかどうかはわかりません。Support は「一般的なサポート」のようなものですか?なぜなら、Meta のほとんどすべては何らかの形でサポートだからではないでしょうか?

ところで:Migration は私にはわかりにくいです。なぜなら、「人を第一に考える」人間として、すぐに「ああ、移行全体をどう管理するか」と考えてしまうのですが、カテゴリを見ると、すべてが技術的な移行、スクリプト、エクスポートなどのように見えます。

最近、facebook-migration について話し合ったことがありますが、それは戦略や人、特定の課題に関するものです。ある意味、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での投稿を考えると、コミュニティ管理に入れるべきか、それとも成功に入れるべきでしょうか?

明日か明後日には考えをまとめますが、今日はもう頭が働かないので、すみません!

「いいね!」 1

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

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

クリックして移動

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

→ ロボットに見られたくない場合に備えて非表示にしています。

以下はカテゴリの再編成案です。

  • ニュースとイベント
    • お知らせ
    • ブログ
    • 要約
  • コミュニティ
    • アゴラ(旧:一般)
    • サイトフィードバック
    • 賞賛
    • 比較
    • コミュニティ管理
    • マーケットプレイス
    • ユーザーWiki
    • 管理者Wiki
    • 開発者Wiki
    • システム管理者Wiki
  • ドキュメント
    • Discourse の利用
    • サイト管理
    • 統合
    • Discourse ホスティング(旧:ホスト済み顧客)
    • セルフホスティング
    • Discourse への移行
    • 開発者ガイド
    • 貢献
  • ヘルプ
    • インストール
    • ホスティング
    • 移行
  • 統合
    • WordPress
    • SSO
  • 貢献
    • バグ
    • 機能
    • 開発
    • 翻訳
    • UX
  • カスタマイズ
    • プラグイン
    • 拡張機能
    • テーマ
    • テーマコンポーネント
    • データとレポート

理由:

  • Community は、他のどこにも当てはまらないあらゆるものに関する議論のための活発な場所となり、Wiki、一般議論(#agora)、サイトフィードバック、他のソフトウェアとの賞賛や比較、さらにはコミュニティ管理やマーケットプレイスに関する議論を含む、より大きなDiscourseコミュニティを結びつけます。
  • #news-events は通常の CDCK のコミュニケーション用となります。
  • #help はサポートを受けるための場所となります。
  • #integrate は特定の統合について議論するための場所となります。
  • Documentation は公式のナレッジベースをホストします。
  • #contribute はすべての開発プロセスをホストします。
  • #customize は、データレポートと探索を含め、各Discourseインスタンスを特別なコミュニティにするすべてのものをホストします。

新規ユーザーが来た場合、彼らは(公式の)ドキュメントまたはコミュニティの議論のいずれかにアクセスすることになります…

#welcome タグを提案し、例えば tl0 から tl1 への移行、雰囲気や分野の把握のために、一連の紹介トピックを指し示すようにすると良いでしょう。

おそらくドキュメントは、ドキュメンテーションシステムタグ:#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