おっしゃることはわかります。ただし、それらがドロップダウンに隠されているという事実は、目立つように表示できるサブカテゴリよりもはるかに見えにくくしています。
これは後でまたお話ししますが、サブカテゴリの乱立を避けるために、私がかなり広範囲に使用する予定のものの1つだからです（特定のカテゴリで特定のタググループから少なくとも1つのタグを要求すること）。
一部はその通りだと思いますが、別の部分は「インストール」の継続、つまりセットアップのすべてのことです。さて、Discourseをインストールしましたが、これには信じられないほどクールな機能がすべて備わっており、多くのことを制御できますが、それをコミュニティのニーズに合わせて「形作る」にはどうすればよいでしょうか？この部分は以前、私を非常に落胆させました。なぜなら、すべての設定などは文書化されていますが、a) どこから始めればよいのかを理解することと、b) コミュニティに対する「ビジョン」を設定や構成にどのように反映させるかを理解することに苦労したからです。
ですから、私が考えているのは、初期設定の道のりの周りの追加のレイヤーかもしれません。「サポート」（「一般サポート」とは改名しません。どのように認識していたかを示すために言っていました）は、「稼働中です」または「解決する必要のある特定の С問題があります」という場合のためであり、「起動の準備をするために何をすべきか」という、箱から出したばかりのインストールに関するものではないと思います。
これらすべてから言えるのは、「設定」は管理者の道のりの一部として意味をなすものであり、それは「サポート」と全く同じではないということです。
私のコミュニティとの並行例（適切な会話でそれについてニュースを伝える必要があることを思い出させます）は次のとおりです。糖尿病の猫の飼い主が診断を受け、私たちのコミュニティに参加した場合、カテゴリをどのように整理しますか？私が今決定したのは、「メンバー中心」になり、「たった今到着した、何が何だかわからない」（より丁寧なフランス語の同等語）から始め、「必要な機材を揃える」、「学習する」となり、それからコミュニティの核となる本格的な「サポート」の準備が整うということです。
Discourseについて、かつての私のようにすべてが全く初めての人としてそのように考えると、1) 自己ホストするかどうかを判断してホスティングを選択すること、2) 実際のインストールを完了すること、3) コミュニティを設計し、それをDiscourseの設定に反映させること、が間違いなくあります。そして、この場合、a) ゼロから構築している場合と b) コミュニティが存在し、それを移行したい場合とで区別をする必要があります。私のFacebook移行の課題のトピックで議論したように、セットアップのアプローチは本当に変わると思います。
そして、これが移行のものをどこに置くかという問題につながります。
どちらの物語を語りたいかによって、再び異なると言わざるを得ません。Discourseは既存のコミュニティのDiscourseへの移行を奨励し、促進したいのでしょうか、それともDiscourseでゼロから構築する人々に焦点を当てているのでしょうか？
驚くことではありませんが、私は既存の顧客の移行に焦点を当てることが理にかなっていると主張します。なぜなら、そこに巨大な未開拓の市場があると確信しているからです。
その場合、「移行」があまり深く埋もれてほしくありません。私は個人的に、それをコミュニティ管理の側面として維持したいと考えています（そして現在のコミュニティカテゴリをそのように改名します。「コミュニティ」だけでは曖昧で、当初は「Discourseコミュニティのため」という意味だと誤解しました。コミュニティの設計/構築/管理について、という意味ではありませんでした）。タグでしょうか、それともサブカテゴリでしょうか？少なくともサブカテゴリに値するかもしれません。移行スクリプトや移行に関する技術的なものは、別のトップレベルのカテゴリに入るでしょうか？
あるいは、移行自体がカテゴリであり、コミュニティの既存の側面をDiscourseにどのように適応させ、反映させるかに関する議論、移行の実際のプロセス（実装）へのアプローチ、そして「データ移行」も含まれるのかもしれません。