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