私の意見では、Customization > Theme component タグはサブカテゴリとして機能する方がより目的に適うと思います。少なくとも私にとって、タグに比べて見つけやすいためです。また、近年、テーマコンポーネントは、その Customization > Plugin counterpart（多くは使いやすさのためにテーマコンポーネントに変換されている）と比べて、ますます重要視されるようになっています。より適切な言葉が見つからないため、彼らは「平等な」扱いに値すると思います。結局のところ、彼らは非常に人気があり、現在では Discourse の不可欠な部分となっています。
ご検討いただければ幸いです。私は英語を母国語としていないため、表現が拙くて申し訳ありません。
まったく同感です！現時点ではすべてが少し混乱しています。
以下のような拡張機能専用の新しいカテゴリを検討することをお勧めします。
その後、既存の「壊れた」サブカテゴリをタグにロールバックします。
どう思いますか、@JammyDodger？
私には良く見えます！全面的にサポートします。
シンプルにするために、カテゴリ名を「カスタマイズ」とし、これら4つをタグにする方が理にかなっているか疑問に思います。
最近のほとんどのDiscourseサイトでは、テーマコンポーネントの方が価値が高いことに同意します。
私はその言語が混乱を招くと思います。Admin→Customize（カスタマイズ）はテーマやテーマコンポーネントのみを対象としています。Customization > Theme には、その UI を通じてサイトに導入できるすべてのものが含まれます。
すでに、ユーザーが YML ファイルにテーマを配置し、UI 経由でプラグインの git リポジトリを追加しようとして、時々問題が発生しています。その境界線をなくすと、そうしたエラーがさらに発生しやすくなるだけです。
プラグインはやはり独自の分類に留めておくべきではないでしょうか？
テーマコンポーネントとプラグインの違いは、私の頭の中ではすでに 曖昧 です。
人々がどちらがどちらなのかをより簡単に理解できるようにする取り組みは、きっと大きな助けになるでしょう。
これは少し皮肉な話ですが、長年にわたり WordPress の開発者は、どこに機能を含めるべきかという判断を迫られ、「テーマ」と「プラグイン」のどちらにコードを記述すべきかについて議論が行われていました。今となっては、何でもかんでも JS ブロックになってしまったため、その議論はほとんど懐かしいものになっていますが、コアソフトウェアとの関係性から、コードを「プラグイン」に含めるか「ブロックパターン」に含めるかという判断はまだ必要です。
Discourse のプラグインについては、そのような感覚をこれまで持ったことはありませんでした。主に、長年にわたり人々がいくつかの素晴らしいテーマコンポーネントのハックを生み出してきたからです。もし誰かが「プラグイン」と「テーマコンポーネント」の違いについて私に尋ねたら、私の最初の反応はこうなるでしょう：「一つはインストールに URL フィールドが必要で、もう一つはサイトの再ビルドが必要だ」と。
ええ…特にこのようなトピックを見ると、初心者にとっては違いが曖昧になると思います。
「プラグインを作ってみた」の後に、「テーマコンポーネントを使って全く同じものを作ってみた」と続くのですから 
そして、それは曖昧になるでしょう。なぜなら、違いは目的ではなく、何かをどのようにインストールするかに基づいているからです。それは周囲の世界を見る開発者的なスタイルです 
プラグインが最初だったと思います
タグ付けについて：トピックにタグを付けるのを忘れるよりも、カテゴリを選択するのを忘れる方が簡単だと思われます。すでにタグが付いていないテーマがいくつかあります。
カテゴリーとタグの健全性チェックを行うことに大賛成です。 最近、構造を少し見直すといういくつかの良い提案がありましたので、これらをまとめて、どこに落ち着くか検討します。
メタを新規ユーザーやたまに利用する人にとってより直感的にするものは、何でも良いことだと思います。
専用のコミュニティモデレーターができたことで、これは以前より問題になりにくくなるはずです。（
）私が進みながら整理・編成することで、その多くをカバーできると思います。また、TL3 や TL4 のメンバーもそれなりにいますので、一貫したパターンを強化することで、他の人々も参加しやすくなることを願っています。
私はまだそれをフロントエンドの変更とバックエンドの変更の違いと考えていますが、Ember へのアップグレードによって、その意味が私にも曖昧になってしまいました。 テーマやテーマコンポーネントで、以前よりもはるかに多くのことが可能になったようです（これは、ホスティングされていてプラグインを追加しにくい環境の人には素晴らしいことです:+1:）。
これは非開発者にとって非常に有用な区別だと思います。 赤色は /admin/customize、黄色は app.yml です。新しいカスタマイズを作成したい開発者ではなく、既存のカスタマイズをインストールする管理者であれば、これだけで十分でしょう。
@Decorbuz さんの提案ありがとうございます👍 いくつかのアイデアをまとめて、何ができるか検討します。
スマートフォンはコンピューターなのか、それともそうではないのか、というのと同じ疑問ですね。境界線はそれほど明確ではなくなっています。
だからこそ、すべてのフォーラムは論理的な選択をして物事を整理しなければなりません。アイデアや用途（UXとターゲットが重要）ごとに行うか、それとも技術的な解決策（開発/コードベースの思考）を重視するかです。
ユーザーが探しているものを見つけられる限り、正しい解決策も間違った解決策もありません。
まあ、時々間違った解決策はあります。健全なプラグイン/テーマ/コンポーネントと壊れたものを、正しいタグを見つけなければならないような方法で混ぜ合わせるのは、本当に本当に悪い考えです 
そして一般的に、管理者がしばしば犯す別の間違いがあります。そして、私が正しく記憶していれば、タグドキュメントやMetaによる同様の警告でも言及されていますが、カテゴリはコンテンツの作成を生成するのではなく、空またはトラフィックの少ないカテゴリは物事を混乱させるだけです。
既存の言語はすでに初心者にとって混乱を招いているため、何かを変える必要があります。
不明確だからといって、必ずしもマージする必要があるわけではありません。特に、上記でジャスティンが提案した名前でのマージについてはなおさらです。各カテゴリにより良い説明を追加し、その方法で曖昧さを解消することも可能です。
Customization > Theme および Customization > Theme component は、ランタイム時に適用可能なパッケージ化されたカスタマイズを指します。
Customization > Plugin のトピックは再ビルドを必要とし、ルートアクセス権限を持つユーザーのみが実行できます。これらはサイトの可用性に影響を与える可能性の高い、リスクの高い変更です。
私もそのように考えています。データベースに何かを保存したり、APIの動作を変更したりするためにバックエンド（Rubyコード）に変更が必要な場合は、プラグインが必要になる可能性が高いです。
変更がUIのみの場合は、テーマコンポーネントから始めて、物事がエスカレートしてより複雑になり、バックエンドの変更が必要になった場合は、後でプラグインにフォールバックするのが最善です。
このアイデアは気に入っています。単一のカテゴリに異なるタグを使用するよりも少し複雑ですが、これらの異なるカスタマイズ要素間のより強力な境界線が気に入っています。
テーマは見た目に関するものだけですが、プラグインはインストールするために機械のOSにアクセスする必要があります。これらは非常に異なるものであり、適切なカテゴリがあれば、たとえばカテゴリの最初のトピックで、新しいユーザーにそれらの違いについて文脈を提供できます。インストール方法、開発者向けドキュメントなど。
私の願いが叶いました！
サブカテゴリではありませんが、それでもこの変更には非常に満足しています。
そしてこちらです：
提案ありがとうございます @Decorbuz
このトピックは、最後の返信から24時間後に自動的にクローズされました。新しい返信は許可されていません。