I see what you mean – though the fact they’re hidden in a drop-down makes them much less visible than subcategories, which one can display prominently.
I’ll get back to you on that one, because that’s one thing I’m planning to use quite extensively 
(requiring at least one tag from a given tag group in a given category) to avoid the multiplication of subcategories…
I think some of it is, but another part of it is the continuation of “installation”, all the setup stuff. Right, now I’ve got Discourse installed, it has all this incredibly cool functionalities, I have control over so many things, but how do I “mold” it into what my community needs? That part had me extremely discouraged some time back, because although all the settings and stuff are documented, I had trouble a) understanding where to start and b) understanding how to translate my “vision” for my community into settings and configuration.
So maybe what I’m thinking of is an extra layer around the journey of initial configuration. I see Support (I wouldn’t rename it “General support”, I was saying that to indicate how I perceived it) more for “I’m up and running, of I have a specific issue I need solving”, rather than “I have my out-of-the box install and now what do I need to do to get it ready for some kind of launch”.
All this to say I actually think that “configuration” does make sense as part of the admin journey and that is not exactly the same as “support”.
A parallel with my community – reminds me I need to give some news about that in the proper conversation – is the following: considering the owner of a diabetic cat who just got a diagnosis and joins our community, how do we organise categories? What I’ve decided upon now is the be very “member centric” and start with “I’ve just arrived, wtf” (some more polite French equivalent), then “I’m getting the gear I need”, “I’m learning” – and then they are ready for the proper “support” that is the heart of the community.
If I think along those lines with Discourse, as somebody who is completely new to it all as I was, there is definitely: 1) figuring how if I’m going to self-host or not and picking my hosting; 2) going through the actual installation 3) designing my community and translating that into Discourse configuration. And in that case there is a distinction to be made between a) I’m building from scratch and b) the community exists and I want to migrate it – as discussed in my facebook migration challenges topic I really think it changes the approach to setting things up.
Which brings us to where to put the migration stuff.
I’d say that again, it depends on what story we want to tell. Does Discourse want to encourage and facilitate the migration of existing communities to Discourse, or is the focus more on people who are going to be building from scratch with Discourse?
No surprise, I’d argue that it makes sense to focus on migrating customers, because I’m persuaded there is a huge untapped market there.
In that case, I would want “Migration” to not be buried too deep. I’d personally keep it as an aspect of Community Management (and rename the current Community category that, because “Community” alone is ambiguous, I initially thought it was “for the Discourse community” rather than “about designing/building/managing communities”. Tag or subcategory? Might at least deserve a subcategory. Would migration scripts and technical stuff around migration go in a different top-level category?
Or Maybe Migration is a category in and of itself, which contains discussions around how one adapts and translates existing aspects of the community into Discourse, how to approach the actual process of migrating (implementation), and also “data migration”.