Entendo o que você quer dizer – embora o fato de estarem ocultas em um menu suspenso as torne muito menos visíveis do que as subcategorias, que podem ser exibidas de forma proeminente.
Voltarei a esse ponto, porque é algo que planejo usar extensivamente 
(exigir pelo menos uma tag de um determinado grupo de tags em uma determinada categoria) para evitar a multiplicação de subcategorias…
Acho que parte disso é, mas outra parte é a continuação da “instalação”, todo o trabalho de configuração. Certo, agora que instalei o Discourse, ele tem todas essas funcionalidades incrivelmente legais, tenho controle sobre tantas coisas, mas como eu o “moldoo” para o que minha comunidade precisa? Essa parte me desanimou muito em certo momento, porque embora todas as configurações e coisas sejam documentadas, tive dificuldade em a) entender por onde começar e b) entender como traduzir minha “visão” para minha comunidade em configurações e ajustes.
Então, talvez o que estou pensando seja uma camada extra em torno da jornada da configuração inicial. Vejo Support (eu não o renomearia para “Suporte geral”, eu estava dizendo isso para indicar como eu o percebia) mais para “Estou funcionando, ou tenho um problema específico que preciso resolver”, em vez de “Tenho minha instalação padrão e agora o que preciso fazer para prepará-la para algum tipo de lançamento”.
Tudo isso para dizer que, na verdade, acho que “configuração” faz sentido como parte da jornada de administração e não é exatamente o mesmo que “suporte”.
Um paralelo com minha comunidade – me lembra que preciso dar notícias sobre isso na conversa apropriada – é o seguinte: considerando o dono de um gato diabético que acabou de receber um diagnóstico e entra em nossa comunidade, como organizamos as categorias? O que decidi agora é ser muito “centrado no membro” e começar com “Acabei de chegar, e agora?” (algum equivalente em francês mais educado), depois “Estou adquirindo o equipamento necessário”, “Estou aprendendo” – e então eles estão prontos para o “suporte” adequado que é o coração da comunidade.
Se eu pensar dessa forma com o Discourse, como alguém completamente novo em tudo isso como eu era, definitivamente há: 1) descobrir se vou auto-hospedar ou não e escolher minha hospedagem; 2) passar pela instalação real 3) projetar minha comunidade e traduzir isso em configuração do Discourse. E nesse caso, há uma distinção a ser feita entre a) estou construindo do zero e b) a comunidade existe e quero migrá-la – como discutido no meu tópico desafios de migração do Facebook eu realmente acho que muda a abordagem para configurar as coisas.
O que nos leva a onde colocar as coisas de migração.
Eu diria que, novamente, depende da história que queremos contar. O Discourse quer incentivar e facilitar a migração de comunidades existentes para o Discourse, ou o foco é mais nas pessoas que vão construir do zero com o Discourse?
Sem surpresa, eu argumentaria que faz sentido focar na migração de clientes, porque estou convencido de que há um enorme mercado inexplorado lá.
Nesse caso, eu gostaria que “Migração” não ficasse muito enterrada. Eu pessoalmente manteria isso como um aspecto do Gerenciamento de Comunidade (e renomearia a categoria atual Comunidade para isso, porque “Comunidade” sozinha é ambígua, inicialmente pensei que fosse “para a comunidade Discourse” em vez de “sobre projetar/construir/gerenciar comunidades”). Tag ou subcategoria? Talvez mereça pelo menos uma subcategoria. Scripts de migração e coisas técnicas sobre migração iriam para uma categoria de nível superior diferente?
Ou talvez Migração seja uma categoria em si, que contém discussões sobre como adaptar e traduzir aspectos existentes da comunidade para o Discourse, como abordar o processo real de migração (implementação) e também “migração de dados”.