Capisco cosa intendi, anche se il fatto che siano nascosti in un menu a discesa li rende molto meno visibili delle sottocategorie, che si possono visualizzare in modo prominente.
Ti risponderò su questo, perché è una cosa che ho intenzione di usare in modo piuttosto estensivo 
(richiedere almeno un tag da un dato gruppo di tag in una data categoria) per evitare la moltiplicazione delle sottocategorie…
Penso che una parte lo sia, ma un’altra parte è la continuazione dell’“installazione”, tutto il lavoro di configurazione. Bene, ora ho installato Discourse, ha tutte queste funzionalità incredibilmente interessanti, ho il controllo su così tante cose, ma come lo “modello” in base alle esigenze della mia community? Questa parte mi ha scoraggiato moltissimo tempo fa, perché anche se tutte le impostazioni e le cose sono documentate, ho avuto difficoltà a) a capire da dove iniziare e b) a capire come tradurre la mia “visione” per la mia community in impostazioni e configurazione.
Quindi forse quello che sto pensando è un livello aggiuntivo attorno al percorso della configurazione iniziale. Vedo Support (non lo rinominerei “Supporto generale”, lo stavo dicendo per indicare come lo percepivo) più per “Sono operativo, o ho un problema specifico che devo risolvere” piuttosto che “Ho la mia installazione appena tolta dalla scatola e ora cosa devo fare per prepararla per un qualche tipo di lancio”.
Tutto questo per dire che in realtà penso che la “configurazione” abbia senso come parte del percorso di amministrazione e che non sia esattamente la stessa cosa del “supporto”.
Un parallelo con la mia community – mi ricorda che devo dare qualche notizia a riguardo nella conversazione appropriata – è il seguente: considerando il proprietario di un gatto diabetico che ha appena ricevuto una diagnosi e si unisce alla nostra community, come organizziamo le categorie? Quello che ho deciso ora è essere molto “incentrato sui membri” e iniziare con “Sono appena arrivato, che diavolo faccio” (un equivalente francese più educato), poi “Sto prendendo l’attrezzatura di cui ho bisogno”, “Sto imparando” – e poi sono pronti per il vero “supporto” che è il cuore della community.
Se penso in questi termini con Discourse, come qualcuno che è completamente nuovo a tutto come lo ero io, ci sono sicuramente: 1) capire se ospiterò io stesso o meno e scegliere l’hosting; 2) passare attraverso l’installazione vera e propria 3) progettare la mia community e tradurla nella configurazione di Discourse. E in quel caso c’è una distinzione da fare tra a) sto costruendo da zero e b) la community esiste e voglio migrarla – come discusso nel mio argomento sfide di migrazione da Facebook penso davvero che cambi l’approccio alla configurazione.
Il che ci porta a dove mettere le cose relative alla migrazione.
Direi che di nuovo, dipende da quale storia vogliamo raccontare. Discourse vuole incoraggiare e facilitare la migrazione di community esistenti su Discourse, o l’attenzione è più rivolta alle persone che costruiranno da zero con Discourse?
Nessuna sorpresa, direi che ha senso concentrarsi sulla migrazione dei clienti, perché sono persuaso che ci sia un enorme mercato inutilizzato lì.
In tal caso, vorrei che “Migrazione” non fosse sepolta troppo in profondità. Personalmente la manterrei come un aspetto della Gestione della Community (e rinominerei la categoria Community attuale, perché “Community” da solo è ambiguo, inizialmente pensavo fosse “per la community di Discourse” piuttosto che “sulla progettazione/costruzione/gestione di community”). Tag o sottocategoria? Potrebbe almeno meritare una sottocategoria. Gli script di migrazione e le cose tecniche relative alla migrazione andrebbero in una categoria di primo livello diversa?
O Forse Migrazione è una categoria a sé stante, che contiene discussioni su come si adattano e traducono gli aspetti esistenti della community in Discourse, come affrontare il processo effettivo di migrazione (implementazione), e anche la “migrazione dei dati”.