Entiendo a lo que te refieres, aunque el hecho de que estén ocultas en un menú desplegable las hace mucho menos visibles que las subcategorías, que uno puede mostrar de forma destacada.
Volveré sobre eso, porque es algo que planeo usar de forma bastante extensa 
(exigir al menos una etiqueta de un grupo de etiquetas determinado en una categoría dada) para evitar la multiplicación de subcategorías…
Creo que parte de ello lo es, pero otra parte es la continuación de la “instalación”, todo el tema de la configuración inicial. Bien, ya tengo Discourse instalado, tiene todas estas funcionalidades increíblemente geniales, tengo control sobre muchísimas cosas, pero ¿cómo lo “moldeo” para que se adapte a las necesidades de mi comunidad? Esa parte me desanimó muchísimo hace algún tiempo, porque aunque todos los ajustes y demás están documentados, tuve problemas a) para entender por dónde empezar y b) para entender cómo traducir mi “visión” para mi comunidad en ajustes y configuración.
Así que quizás lo que estoy pensando es una capa adicional en torno al recorrido de la configuración inicial. Veo Support (no lo cambiaría a “Soporte general”, lo decía para indicar cómo lo percibía) más para “Estoy en funcionamiento, o tengo un problema específico que necesito resolver”, en lugar de “Tengo mi instalación tal cual viene de fábrica y ahora ¿qué necesito hacer para prepararla para algún tipo de lanzamiento?”.
Todo esto para decir que en realidad creo que “configuración” tiene sentido como parte del recorrido del administrador y que no es exactamente lo mismo que “soporte”.
Un paralelismo con mi comunidad —me recuerda que tengo que dar noticias sobre eso en la conversación adecuada— es el siguiente: considerando al dueño de un gato diabético que acaba de recibir un diagnóstico y se une a nuestra comunidad, ¿cómo organizamos las categorías? Lo que he decidido ahora es ser muy “centrado en el miembro” y empezar con “Acabo de llegar, ¿qué demonios hago?” (algún equivalente en francés más educado), luego “Estoy consiguiendo el equipo que necesito”, “Estoy aprendiendo” —y entonces están listos para el “soporte” propiamente dicho que es el corazón de la comunidad.
Si pienso en estas líneas con Discourse, como alguien que no sabe nada de todo esto como yo lo fui, definitivamente hay: 1) averiguar si voy a alojarlo yo mismo o no y elegir mi alojamiento; 2) pasar por la instalación real 3) diseñar mi comunidad y traducirlo en configuración de Discourse. Y en ese caso hay que hacer una distinción entre a) construir desde cero y b) la comunidad ya existe y quiero migrarla; como se discutió en mi tema sobre desafíos de migración desde Facebook realmente creo que cambia el enfoque para configurar las cosas.
Lo que nos lleva a dónde poner las cosas de migración.
Yo diría que de nuevo, depende de la historia que queramos contar. ¿Quiere Discourse fomentar y facilitar la migración de comunidades existentes a Discourse, o el enfoque está más en las personas que van a construir desde cero con Discourse?
No es ninguna sorpresa, argumentaría que tiene sentido centrarse en migrar clientes, porque estoy convencido de que hay un gran mercado sin explotar ahí.
En ese caso, querría que “Migración” no estuviera enterrada demasiado. Personalmente, la mantendría como un aspecto de Gestión de la Comunidad (y cambiaría el nombre de la categoría actual Comunidad a eso, porque “Comunidad” por sí sola es ambiguo, inicialmente pensé que era “para la comunidad de Discourse” en lugar de “sobre el diseño/construcción/gestión de comunidades”). ¿Etiqueta o subcategoría? Podría merecer al menos una subcategoría. ¿Los scripts de migración y las cosas técnicas sobre la migración irían en una categoría principal diferente?
O quizás Migración es una categoría en sí misma, que contiene discusiones sobre cómo uno adapta y traduce los aspectos existentes de la comunidad a Discourse, cómo abordar el proceso real de migración (implementación), y también la “migración de datos”.