たくさんのガイドがあります。時には @dax や @jomaxro が、私が知らなかった howto ガイドを共有してくれて、感心することもあります！
Discourse のメタフォーラムにいる多くの新規ユーザーやコミュニティマネージャーも、同じように感じているようです。そこでこの課題を解決するため、@justin が素晴らしいアイデアを提案してくれました。私たちの howto をカテゴリ分けし、誰もがより良い出発点を持てるようにすることです。最終的には、https://support.teams.discourse.com/docs のような形になることを目指しています。
現在、以下の 3 つのカテゴリを検討しています：
あなたが考える howto は、どのカテゴリに分類されますか？
皆さんのアイデアをお聞かせください 
ここでは誰も反応しないと思います。この作業を引き受ける動機が人々にはないからです。
私たちのチームに割り当てるか、もっと簡単にする方法（タグなど）を見つける必要があります。
これだけたくさんありますね 
どうやら私が間違っていたようです！ありがとう。
ハハ、確かにたくさんありますね！理想としては、カテゴリごとに6〜12件のハウツーを掲載できれば素晴らしいです。すべてを分類するのではなく、ユーザーが最も探しているものを厳選して分類するつもりです。
@osioke さんへの提案ですが、このカテゴリに関連する閲覧数の多いハウツーを探し、上位6〜12件をタグ付けするというアプローチがあります。@Benjamin_D さんの提案と組み合わせれば、簡単な着手点になるでしょう！
タグの素晴らしい点は、進捗に合わせて簡単に編集できることです。
@Benjamin_D、共有ありがとうございます！私が特に悩んでいたのは、どのように提示し、構造をどう捉えるかという点でしたが、あなたの表は非常に役立ちました。
現在、グループを3つから6つに拡張しようとしています：
@justin が共有してくれたように、最も閲覧されているものを確認し、上位20件をリストしました：
どう思いますか？
これは大きな変更となるため、大物に助言を仰ぎ、@trust_level_3 を cc させていただきます。
うーん、ログイン設定に関する記事は、それだけでカテゴリを設けてもいいかもしれませんね。これは「はじめに」のサブセットですが、新しいサイトを立ち上げた際に最初に行いたいことのひとつだからです（もちろん、設定したい場合に限りますが）。
マルチサイトについてここで言及する必要があるかどうかはわかりません 
。あるいは、高度な設定グループに警告を添えることもできます。検索メタ！例えば、この投稿は非常に役立ちます pros-and-cons-of-a-multisite-installation。
Sending Bulk User Invites については、最近は multiple-use-invite-links を使う傾向にあります。両方のトピックに触れるべきかもしれません。
Set up Reply via Email Support 
は、高度な設定グループに配置するのが良いと思います（まだやっていないので 
）。straightforward-direct-delivery-incoming-mail も触れる価値があると思いますが、おそらく高度な設定グループで。なぜなら…まあ…メールですから 
。
コントリビューショングループは少し空っぽに感じます。テーマやコンポーネントに関連する何かを入れると良いかもしれません。例えば、developer-s-guide-to-discourse-themes、designers-guide-to-discourse-themes、beginners-guide-to-using-theme-creator-and-theme-cli-to-start-building-a-discourse-theme などです。
その通りですね。このリストは閲覧数トップ20に基づいており、並べ替えの考え方を示すために共有しました。これは決して最終リストではなく、もう少し明確に伝えるべきでした:sweat_smile:
継続的な管理やモデレーション活動のためのカテゴリとして、「管理」または「運用」を追加したいと考えています。これはセットアップ/設定には該当せず、開発/ドキュメント（貢献）にも当てはまりません。
Discourse for Teams のドキュメントサイトが、すべてのドキュメントに Discourse を使用しているものと推測します。コミュニティの誰もが参加できる Discourse のハウツーサイトとしてこれを使う場合の課題は、バージョン管理と全件の追跡です。Discourse をこの目的に使うことが望ましい方法であることは確かですが、Hugo サイトやJekyll サイトを採用し、ドキュメントを GitHub 上のファイルとして扱い、誰でもプルリクエストを出せるようにするのはどうでしょうか。もしそれらがお好みに合わない場合でも、GitHub リポジトリベースのドキュメントシステムは他にも多数あり、さまざまな種類があります。
ああ、Discourse ならバージョン管理は非常にうまく機能します。さらにカテゴリへのアクセス権限セキュリティを組み合わせれば、私たちが誇りを持って利用している仕組みが完成します;)
その通りですね。それに該当する投稿の例をいくつか共有してもらえますか？
参考までに、#howto:sysadmin の整理を少しずつ進めています。各記事が最新で関連性があるか確認し、その後に auto-delete-posts-after に移動させる作業を行っています。それらの大半は、ここでは advanced config として分類されているようです。
完全に同意します。マルチサイトは非常に高度な設定であり、Meta ではあまりサポートしていません。
その通りです。Discourse と Docs プラグイン、さらにいくつかのカスタマイズを組み合わせています。この用途では Discourse を使用する方が好ましいですが、Wiki や SSG サイトを使用する利点も確かにあります。
このような作業をしていただき、本当にありがとうございます
「サポートが限定的」なトピックを、明確にマークされた独自のカテゴリにまとめることができれば素晴らしいと思います。
ここに記載されていれば、何らかの形でサポートが提供されるべきだという考え方が現状ではあるようです。
また、そのような機能はリリース間で脆弱であったり、広くテストされていないことが多いため、アップグレード前にユーザーにテストを促す際の根拠としても役立ちます。
サブフォルダ、マルチサイト、ターシャリーカテゴリなどはすべてこのカテゴリーに該当するでしょうか？
マルチサイトはほぼ「サポートされている」と言えますが、その道を選んだ場合は、より多くのことが求められることを理解していることが前提となります（例えば、さまざまな文脈における rebuild app の意味について考える必要があります）。私はこれを「上級」と呼ぶでしょうが、「超・超・上級」ではありません。
ターシャリカテゴリとサブフォルダは「超・超・上級」であるという点には同意します。
マルチサイト環境における Let’s Encrypt の運用について考えているのかもしれません。これは長年にわたり繰り返し問題が発生しており、更新されたドキュメントが公開されるまでに数週間から数ヶ月を要することもありました。
ああ、そうですか。確かに、それは現在かなり安定していると思います（最後の修正は nginx でのリダイレクトの扱いに関するものだったと記憶しています）。また、Multisite Configuration with Let's Encrypt and no reverse proxy - Documentation - Literate Computing Support という記事も、このスレッドに「まもなく」投稿する予定でいます（これは 2020 年 12 月 2 日に作成し、最後にテストしたものです）。ただし、マルチサイト構成は、基本的に自己責任で進める必要がある点は確かです。少なくとも 3 つ（もしかしたら 10 個？）のサイトがない限り、マルチサイト構成を採用する意味はあまりないと思います。なぜなら、マルチサイトが必要だと思っている人の多くは、単一の 1GB ドロプレットでやり過ごそうとしているように見えるからです。
最も役立つのは、カテゴリ（ハウツー）の構造にさらに力を注ぐのではなく、ドキュメント自体の構造をより良くすることです。
ユーザーが自由に投稿できる、流動的なフォーラムであることは非常に価値があると思います。そのためには、上位のカテゴリを適切に設定し、ユーザーが適切なカテゴリに投稿することが重要です。しかし、サブカテゴリが複雑になり、ユーザーがどのサブカテゴリに投稿すべきか、あるいはどこで情報を探すべきかを気にする必要がある場合、それはやや妨げになると感じます。
現在、ドキュメントは実質的にフォーラムの構造をそのまま反映しています：
代わりに、スタッフ専用のタグ（例：‘docs-getting-started’、‘docs-setup’ など）を使って、フォーラムのあらゆる場所からコンテンツを収集し、ドキュメントを整理・構成するのはどうでしょうか。そうすれば、単なるフォーラムの鏡像ではなく、適切にキュレーションされた目次を持つドキュメントページを作成できます。例えば以下のようなものです：
ドキュメント
@manuel、まさにその通りです！私たちは、これらのハウツーを簡単にフィルタリングできる仕組みを作りたいと考えていますが、既存の Docs プラグインのフィルタも維持したいと考えています。これらのハウツーを特定のタグに整理することが、最初の着手点となります。
