Я понимаю, что вы имеете в виду, хотя тот факт, что они скрыты в выпадающем меню, делает их гораздо менее заметными, чем подкатегории, которые можно разместить на видном месте.
Я вернусь к этому вопросу, потому что это одна из вещей, которую я планирую использовать довольно широко 
(требование наличия хотя бы одного тега из определённой группы тегов в конкретной категории), чтобы избежать умножения подкатегорий…
Я думаю, часть этого так и есть, но другая часть — это продолжение «установки», все этапы настройки. Да, теперь у меня установлен Discourse, он обладает всеми этими невероятно крутыми функциями, я контролирую так много вещей, но как мне «придать форму» в соответствии с потребностями моего сообщества? Этот аспект сильно демотивировал меня некоторое время назад, потому что, хотя все настройки и прочее задокументированы, у меня возникали трудности: а) пониманием, с чего начать, и б) пониманием того, как перевести своё «видение» для сообщества в настройки и конфигурацию.
Поэтому, возможно, то, о чём я думаю, — это дополнительный слой вокруг пути первоначальной конфигурации. Я вижу Support (я бы не стал переименовывать его в «Общая поддержка», я сказал это, чтобы показать, как я его воспринимаю) скорее для случаев «Я запустился, но у меня есть конкретная проблема, которую нужно решить», а не «У меня есть установка из коробки, и что мне теперь нужно сделать, чтобы подготовить её к запуску».
Всё это к тому, что я на самом деле считаю, что «конфигурация» имеет смысл как часть пути администратора, и это не совсем то же самое, что «поддержка».
Аналогия с моим сообществом — напоминает, что мне нужно сообщить новости об этом в соответствующей теме, — следующая: если представить владельца кошки-диабетика, который только что получил диагноз и присоединяется к нашему сообществу, как нам организовать категории? То, на чём я сейчас остановился, — это быть очень «ориентированным на участника» и начать с «Я только что arrived, черт возьми» (более вежливый французский эквивалент), затем «Я получаю необходимое оборудование», «Я учусь» — и только потом они готовы к настоящей «поддержке», которая является сердцем сообщества.
Если я мыслю в таком ключе о Discourse, как человек, который совершенно новичок во всём этом, как и я, то определённо есть: 1) выяснение, буду ли я использовать самостоятельный хостинг или нет, и выбор хостинга; 2) прохождение самой установки; 3) проектирование моего сообщества и перевод этого в конфигурацию Discourse. И в этом случае необходимо провести различие между а) созданием с нуля и б) существующим сообществом, которое я хочу мигрировать — как обсуждалось в моей теме проблемы миграции с Facebook, я действительно считаю, что это меняет подход к настройке.
Что подводит нас к вопросу о том, куда поместить материалы по миграции.
Я бы сказал, что снова это зависит от той истории, которую мы хотим рассказать. Хочет ли Discourse поощрять и облегчать миграцию существующих сообществ в Discourse, или фокус больше на людях, которые будут строить с нуля на базе Discourse?
Неудивительно, я бы утверждал, что имеет смысл сосредоточиться на миграции клиентов, потому что я убеждён, что там существует огромный неиспользованный рынок.
В этом случае я бы хотел, чтобы «Миграция» не была слишком глубоко скрыта. Я бы лично сохранил её как аспект управления сообществом (и переименовал бы текущую категорию Community в это, потому что «Community» в одиночку неоднозначна: изначально я думал, что это «для сообщества Discourse», а не «о проектировании/создании/управлении сообществами». Тег или подкатегория? Возможно, заслуживает хотя бы подкатегории. Должны ли скрипты миграции и технические вопросы вокруг миграции находиться в отдельной категории верхнего уровня?
Или, возможно, Миграция — это отдельная категория, которая содержит обсуждения о том, как адаптировать и переводить существующие аспекты сообщества в Discourse, как подходить к самому процессу миграции (реализация), а также «миграция данных».