개인적인 의견으로는, Customization > Theme component 태그가 하위 카테고리로 사용되면 그 목적을 더 잘 달성할 수 있을 것 같습니다. 적어도 제 경우엔 태그보다 찾기 쉬웠고, 최근 몇 년간 테마 컴포넌트는 플러그인 버전(Customization > Plugin)에 비해 점점 더 중요해지고 있습니다(많은 플러그인이 더 쉬운 사용을 위해 테마 컴포넌트로 전환되고 있죠). 더 적절한 표현이 떠오르지 않지만, 이들은… “동등한” 대우를 받아야 합니다. 결국, 이들은 매우 인기 있고 오늘날 디스코urs의 필수적인 부분이기 때문입니다.
이 점을 고려해 주시기를 바랍니다. 저는 영어를 모국어로 사용하지 않기 때문에 표현이 부족할 수 있어 죄송합니다. 
전적으로 동의합니다! 지금은 상황이 좀 엉망이죠.
다음과 같은 하위 카테고리를 가진 확장(Extensions) 전용 새 카테고리를 추가하는 것을 제안합니다:
그리고 기존 broken 하위 카테고리는 태그로 통합하는 것입니다.
@JammyDodger님은 어떻게 생각하시나요?
[quote=“nathank, post:2, topic:223862”]
다음과 같은 하위 카테고리를 갖춘 확장(Extensions) 전용 새 카테고리를 고려해 보시는 것을 제안합니다:
그리고 기존 broken 하위 카테고리를 태그로 통합하겠습니다.
[/quote]나쁘지 않네요! 전적으로 지지합니다. 
단순성을 위해 한 단계 더 나아가 카테고리를 customize로 표시하고 대신 이 네 가지를 태그로 사용하는 것이 더 합리적이지 않을까 싶습니다.
요즘 대부분의 Discourse 사이트에서 테마 컴포넌트가 조금 더 유용하다는 점에는 동의합니다.
이 표현이 혼란을 초래할 것 같습니다. Admin->Customize(관리자->커스터마이즈)는 테마와 테마 컴포넌트에만 적용됩니다. #customization:theme에는 해당 UI를 통해 사이트에 도입할 수 있는 모든 항목이 포함되어 있습니다.
이미 사용자들이 테마를 YML 파일에 넣고, 플러그인을 위한 git 저장소를 UI를 통해 추가하려는 시도로 인해 간헐적인 문제가 발생하고 있습니다. 이러한 구분을 없애면 오히려 그런 오류가 더 자주 발생할 가능성이 높아집니다.
플러그인은 정말로 자체 카테고리로 유지되어야 하지 않나요?
제 머릿속에서 테마 컴포넌트와 플러그인의 경계는 이미 모호해졌습니다. 
둘 중 어느 것이 무엇인지 사용자가 더 쉽게 알아볼 수 있도록 도와주는 모든 시도는 큰 도움이 될 것이라고 확신합니다.
이건 좀 웃기기도 한데요, 오랫동안 워드프레스 개발자들은 기능을 어디에 포함해야 하는지에 대해 고민해 왔고, 코드의 어느 정도가 "테마"에, 어느 정도가 "플러그인"에 속해야 하는지에 대한 논쟁이 벌어졌습니다. 지금은 모든 것이 JS 블록이 되어 그 논쟁은 거의 고전처럼 느껴지지만, 코어 소프트웨어와의 관계 때문에 여전히 코드가 "플러그인"에 들어갈지 "블록 패턴"에 들어갈지 결정해야 합니다.
디스커스에서 플러그인에 대해 그런 명확한 감을 가져본 적이 없습니다. 대부분은 지난 몇 년간 사람들이 몇 가지 훌륭한 테마 컴포넌트 해킹(hacks)을 만들어냈기 때문이죠. 누군가 "플러그인"과 "테마 컴포넌트"의 차이가 무엇인지 물어본다면, 제 첫 번째 생각은 이렇습니다: 하나는 설치할 때 URL 필드를 요구하는 반면, 다른 하나는 사이트 재구축을 요구한다는 것입니다.
네… 초보자의 입장에서는 차이가 모호한 것 같네요. 특히 이런 주제들을 보면요:
“플러그인을 만들었습니다” 바로 뒤에 "테마 컴포넌트를 이용해 똑같은 것을 만들었습니다"라는 글이 나오거든요 
그렇고말고요. 차이는 설치 방식에 기반해 있기 때문이에요. 목적이 아니라요. 주변 세상을 그렇게 보는 건 개발자적인 사고방식이죠 
플러그인이 먼저였던 것 같습니다.
태깅에 대해 간단히 말씀드리자면, 카테고리를 선택하는 것을 잊는 것보다 토픽에 태그를 붙이는 것을 잊기 더 쉬운 것 같습니다. 이미 태그가 없는 테마들이 몇 개 있습니다.
카테고리와 태그에 대한 점검을 해보는 데 적극 찬성합니다. 최근 구조를 조금 조정하자는 좋은 제안들이 몇 건 있었습니다. 그래서 이 모든 내용을 정리해서 어디까지 나아갈 수 있는지 한번 살펴볼 생각입니다. 
메타(Meta)를 신규 사용자나 가끔 사용하는 사람들에게 더 직관적으로 만들어주는 것이라면 좋은 일일 수밖에 없다고 생각합니다.
전담 커뮤니티 모더레이터가 생긴 지금은 이 문제가 덜해질 것입니다. (
) 제가 진행하면서 분류하고 정리하면 상당 부분 커버될 것 같습니다. 또한 TL3과 TL4 등급의 사용자가 적지 않아서, 일관된 패턴을 강화하면 다른 사람들도 더 쉽게 참여할 수 있기를 바랍니다.
저는 여전히 프론트엔드와 백엔드 변경 사항으로 보고 있지만, 엠퍼버(Ember)로의 업그레이드 이후 그 의미가 저에게도 모호해졌습니다. 이전보다 테마/테마 컴포넌트에서 훨씬 더 많은 것이 가능해진 것 같습니다(호스팅을 사용하고 플러그인을 쉽게 추가할 수 없는 환경이라면 이는 큰 장점입니다 ).
개발자가 아닌 사람들에게는 꽤 유용한 구분이 될 것 같습니다. 빨간색 = /admin/customize, 노란색 = app.yml. 새로운 커스터마이징을 개발하려는 개발자가 아니라, 기존 커스터마이징을 설치하는 관리자라면 이것만 알아도 충분할 것입니다.
@Decorbuz 제안 감사합니다. 몇 가지 아이디어를 정리해서 해볼 수 있는 일이 있는지 알아보겠습니다.
더 똑똑한 폰이 컴퓨터인지 아닌지에 대한 질문과 같은 맥락입니다. 경계가 더 이상 명확하지 않으니까요.
그래서 모든 포럼은 사물을 어떻게 배열할지에 대해 논리적인 선택을 해야 합니다. 어딘가에서는 아이디어나 용도(UX 및 대상이 중요)에 따라 구분해야 할지, 아니면 기술적 해결책(개발/코드 기반 사고)이 더 중요한지 결정해야 합니다.
사용자가 원하는 것을 찾을 수만 있다면 정답이나 오답은 없습니다.
물론 가끔은 잘못된 선택도 있습니다. 정상적인 플러그인/주제/컴포넌트와 깨진 것들을 섞어 놓아서 올바른 태그를 찾아내야 하는 상황은 정말로 정말 나쁜 아이디어입니다 
그리고 일반적으로 관리자가 자주 범하는 또 다른 실수가 있습니다. 기억이 맞다면, Meta의 태그 문서나 유사한 문서에서도 경고하듯, 카테고리는 콘텐츠 생성을 유도하지 않으며, 비어 있거나 트래픽이 낮은 카테고리는 그저 상황을 혼란스럽게 만듭니다.
기존의 표현이 이미 초보자에게 혼란을 주고 있으므로, 반드시 변경이 필요합니다.
명확성이 부족하다고 해서 반드시 병합해야 하는 것은 아닙니다. 특히 Justin이 위에서 제안한 이름으로 병합하는 것은 더욱 그렇습니다. 대신 각 범주에 더 나은 설명을 추가하여 모호성을 해결할 수도 있습니다.
#customization:theme와 #customization:theme-component는 런타임에 수행할 수 있는 사전 패키징된 커스터마이징을 포함합니다.
Customization > Plugin 토픽은 재빌드가 필요하며 루트 접근 권한이 있는 사용자만 수행할 수 있습니다. 사이트의 가용성에 영향을 미치는 고위험 변경 사항입니다.
나도 그렇게 생각한다. 백엔드(ruby 코드)에서 어떤 변경이 필요한 경우, 예를 들어 데이터베이스에 무언가를 저장하거나 API 동작을 변경하는 것이라면, 아마도 플러그인이 필요할 것이다.
변경 사항이 UI에만 국한된다면, 나중에 상황이 악화되고 더 복잡해져서 백엔드 변경이 필요하게 될 때까지 테마 컴포넌트로 시작하는 것이 좋다.
이 아이디어를 좋아한다. 단일 카테고리에 다양한 태그를 사용하는 것보다 약간 복잡하지만, 이러한 다른 커스터마이징 요소들 사이의 명확한 경계를 선호한다.
테마는 외관에만 관한 것이지만, 플러그인은 설치하기 위해 기계의 OS에 접근해야 한다. 이들은 매우 다른 것들이며, 적절한 카테고리는 예를 들어 해당 카테고리의 첫 번째 주제가 새로운 사용자에게 두 요소의 차이점에 대한 맥락을 제공할 수 있게 해준다. 설치 방법, 개발 문서 등.
내 소원이 이루어졌어요! 
하위 카테고리는 아니지만, 이 변경 사항에 대해 여전히 매우 기쁩니다.
그리고 여기 있습니다:
좋은 제안 감사합니다 @Decorbuz
이 주제는 마지막 답변 후 24시간이 지나면 자동으로 닫힙니다. 새로운 답변은 더 이상 허용되지 않습니다.