Updating how categories are organized on Meta

Contribute Site feedback
1

As part of updating meta’s theme and structure, we are planning to make some changes to the organization of categories here.

We’ve explored a few different ideas so far, and we expect this will still go through some additional revisions as we get feedback from the community, but the idea that we’re leaning towards now is illustrated below:

meta-redesign-2026-categories-v1
meta-redesign-2026-categories-v11391×867 106 KB

The basic idea is to group related categories into a smaller number of top level categories, each of which would be in the sidebar for new users by default.

  • News and Events
  • Support
  • Community Success
  • Contribute
  • Customization
  • Documentation
  • Community wiki
  • Marketplace

We expect Support to continue to be one of the most active categories, and think it may reduce choice paralysis to group other support related categories underneath it. There are probably further refinements worth making here (should SSO be a category or a tag? what’s the difference in practice between Installation and Hosting? should those be collapsed into a single Self Hosting subcategory?) We’ll work through those questions as we go, but the general shape is to have all support topics in one place.

Community Success is a category we’d love to invest in more, building upon the existing Community category. We see this as a place where everyone involved in running a successful Discourse community can support each other, not with technical support, but with the messy soft stuff of what it takes to build a successful community. We’ll likely reshape the underlying structure here too, but for starters, we think the existing Community and Data and Reporting categories are the main pillars here.

Contribute is the category we envision being the center for discussion about how to improve the product itself, and this community.

Customization would be a place to find all topics related to extending Discourse with plugins, themes, components and other extensions.

If you’d like to take a closer look, we have this structure currently in place on a staging site where you can take a look around.

how to access the staging site
  1. Visit https://meta-redesign-2026.discourse.group/
  2. Enter this user and password for HTTP basic auth
    • user: meta2026bsbx
    • pass: Q0U1ppbVbd2MVttuYOl+M8SYEOUqGLGjzl5sr1C9XwE=
  3. Enter your email/username and password for meta
    (the staging site does not support any other login methods).

After you’ve had a chance to do so, please let us know what you think here.

5 Likes
Updating Meta's theme and structure
2

I think that having a category called something like self-hosting might help make it clear what goes there. It’s still not a great name, but it’s better than Installation, which implies discourse has never worked; I was quite confused the first time one of my topics got moved there. Maybe “back-end” would work?

If you access a shell to cause or witness your problem, it goes there. If discourse “works” and it’s something to do with ux or themes or anything else, it goes on support.

7 Likes
3

I’m in favor.

I’d go further and say we should combine Installation and Installation > Hosting into this new Self-Hosting category.

I think we could do that regardless of how the rest shapes up. If we go in the direction I’ve sketched out above, this new category would be a subcategory of Support.

If we stick closer to the current flat model, it’d be a top level category.

4 Likes
4

I’ve just made the following change, resulting in a new top level Self-hosting support category:

  • Tagged all topics previously in Installation > Hosting with hosting
  • Merged all topics from Installation > Hosting to what used to be Installation
  • Renamed Installation to Self-hosting support

Maybe “Self-hosting” is better than “Self-hosting support” (especially if we move it under Support), but as a first step for now, I went with something a bit more verbose, that has the word “support” in it.

3 Likes
5

FWIW I avoided ‘self hosting support’ previously as it gave the appearance that that was the area specifically for self hosters to get all their support and I didn’t want to have that as a first impression.

It’s also very similar to the docs category, and you don’t really want duplication if you’re looking to simplify.

Configuration was also discounted as all the features/settings/plugins/etc need ‘configuring’, so was not descriptive enough. Sys-admin was considered too technical (when we wanted to downplay how technical you need to be to run a Discourse site).

Though I agree that installation was ambiguous, though it didn’t cause that much confusion in practice. A better name is out there though… :slight_smile:

For Hosting, that was the area to discuss the underlying services (digital ocean, mailgun, etc, etc). I think it did have a distinct flavour that was different from server administration, and with over 500 topics it would be viable for a conversation to be split out (if it hadn’t already existed :slight_smile:)

8 Likes
6

For me, this is what I’d expect:

  • hosting: about choosing and managing the host (server)
  • Installation: getting to « discourse exists and I can log in as admin and do stuff »
  • configuration: all the nitty-gritty regarding the various settings

I think that for somebody starting out, the distinction between core and « plugin bundled in » is not very obvious. So I’d include those in configuration— or at least very clear pointers.

3 Likes
7

Which of those would you expect to be different categories vs. different tags?

And how would you expect those relate to the Support category?

2 Likes
8

So, I think I’d be OK with installation and hosting being tags. But I’m wondering (for my community too) if there is a way to “pin” or “put forward” certain key tags in a category. They could also be categories (if we think along the lines of “telling the story”).

Configuration: is this going to be very different for self-hosters or hosted admins? I have the impression it will overlap, so I’m not sure I’d have it locked inside Self-hosting (which I’d rename that rather than Self-hosting support). Maybe Support is more like “General support”? Because almost everything in Meta is support in some way, isn’t it?

By the way: Migration is confusing to me, because as a “people first” person I immediately think “oh, how do I manage the migration as a whole”, and when I look at the category, it seems to be all “technical migration”, scripts and exports and stuff.

We recently had some talks about facebook-migration which is more about strategy and people and specific challenges. In a way, I feel like Migration may act as an evil attractor for people concerned about the more general or human aspects of migration. See what I mean?

2 Likes
9

Having a greater affordance for this in the app is something that may be worth exploring, but I’m not sure how it should work.

Right now, I think this happens very organically – a critical mass of certain tags accumulates in a given category, and people start to see the pattern and encourage it to flourish.

There are built in features for restricting tags to certain categories, or requiring a number of tags in a given category, particularly from a given tag group, but I feel like they can often be too onerous.

:+1: agreed. I think of configuration as more “general support” (unless its configuring things at the sysadmin layer, like the port you’re listening on, etc).

Yeah, that’s what I first had in mind as well… I’ll let it sit for a day, but will revisit this detail tomorrow.

It is, but I’m not sure how much that extra word helps. I get what you mean, though.

Yeah, it’s possible there are two categories hiding in here. If we were to look at this through the lens of the proposed nested structure, perhaps this should be split into something more like support/migration, and something more like dev/migration.

I could see us shaping that more over time, while making a smaller initial move first here.

10

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 :sweat_smile: (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”.

1 Like
11

Wait. What if there were a way to encourage users to tag topics with #standard-install like we do with unsupported-install?

I’m not quite sure how to make that happen, though.

2 Likes
12

In the current proposal, we’re imagining “Community Success” being the top level category with “Community Management” being a subcategory of that – how does that align with your thinking here?

I do like the idea of having some signposting defined around our understanding of what typical steps of the journey might look like…

1 Like
13

I don’t get the distinction between those two. What would go in Community Success that doesn’t go in Community Management? If I think about the stuff I posted so far in Community here, do I put them in community management or success?

I’ll have to give it a think tomorrow or Friday, brain is checking out for today, sorry!

1 Like
14

Well, aside from the subcategories you see in the mockup there, you mentioned two other activities here aside from managing communities (designing them and building them):

But perhaps that still all falls under “management” for most people.

15
click to go

one click staging site including credentials

→ Hiding in case you don’t want robots going there.

Here would be my reshuffling of categories:

  • News & Events
    • Announcements
    • Blog
    • Summaries
  • Community
    • Agora (was: general)
    • Site Feedback
    • Praise
    • Comparison
    • Community Management
    • Marketplace
    • User Wiki
    • Admin Wiki
    • Dev Wiki
    • Sysadmin Wiki
  • Documentation
    • Using Discourse
    • Site Management
    • Integrations
    • Discourse Hosting (was: Hosted Customers)
    • Self-Hosting
    • Migrating to Discourse
    • Developer Guides
    • Contributing
  • Help
    • Installation
    • Hosting
    • Migration
  • Integrate
    • WordPress
    • SSO
  • Contribute
    • Bug
    • Feature
    • Dev
    • Translations
    • UX
  • Customize
    • Plugin
    • Extras
    • Theme
    • Theme Component
    • Data & Reporting

Rationale:

  • Community would be the lively place for discussions related to anything not done anywhere, bringing together the larger Discourse community, including wikis, general discussion (#agora), site feedback, praise and comparison with other software, but also discussion about community management and the marketplace.
  • #news-events would be for normal CDCK communication
  • #help would be to get support
  • #integrate would be to discuss specific integrations
  • Documentation would host the official knowledge base
  • #contribute would host all the development process
  • #customize would host all that makes each Discourse instance a special community, including data reporting and exploration.

When someone new comes, they would either go to the (official) documentation, or to the community discussions…

I would suggest a #welcome tag pointing to a handful of introduction topics to navigate easily and onboard newcomers, e.g., for going from tl0 to tl1, grasping the mood and areas.

Probably the documentation should have a prominent start with The Documentation System tags: tutorial, explanation, how-to, reference.

Community Management could be called Community Building instead… I don’t like “Community Success” for some unclear reason.

3 Likes
Adding a #welcome tag for newcomers
16

Yes, I’ve done that before on a community and I also think it’s a nice and flexible way to indicate an onboarding path, apart from using any category. Something like
image

4 Likes
Adding a #welcome tag for newcomers
17

I applaud this initiative and appreciate involving us in the process.

Having followed the Discourse journey of @stephtara it is obvious to me Meta needs a dedicated place for new community builders. No idea what to call it but a warm a cozy place for those building with Discourse for the first time would help with the overwhelm from configuration option overload. Folks offering help here would know extra effort and patience might be necessary in replying with help in this area.

Maybe I have missed it but a Config Option doc category with an index that mirrors the “current” admin area would be awesome. Discourse is always evolving. The documentation should do the same by keeping up.

In addition to this category/tag overhaul I am hoping a “fresh sorting out” of existing topics will follow the reorganization. Most of my time on Meta looking for answers is spent trying to sort what info is germane to the current status of Discourse and what is old and not applicable. I confess my BBS is part of the issue but many of the docs are very difficult to sort out. I do appreciate the work staff have done and are stilling doing to improve the docs but many/most seem in need.
To that end I suggest tagging most of the docs or topics that appear to be docs with a Needs Review tag. Yes that would be one huge amount of tags but once the review process was complete the user experience would be improved enormously. I and perhaps others would be willing to help in this effort. An editing tagging sequence could help with managing the process.

I am using this on one site:

Summary

Needs-Review Needs-Text Needs-Citation Needs-Work Ready-to-Publish

Screenshot 2026-02-19 094527
Screenshot 2026-02-19 094527784×117 10.7 KB

Perhaps an Out of Date tag would be helpful.

@mcwumbly Thanks again for initiating this reorganization and including us in the process. :clap:

6 Likes
18

Here’s my plan for next steps:

  • Week of Feb 23
    • Update the category organization here to match what’s in the first post, maybe taking some small liberties based on the feedback so far
    • Expect plenty more discussion feedback here about how it feels in practice
    • Make some small tweaks based on feedback
  • Week of March 2
    • Continue to refine if things are generally feeling good. OR
    • Revert if things are feeling way off
5 Likes
19

Stashing this idea here:

It likely deserves it’s own topic, but we can discuss more here first as part of all this larger shuffle.

3 Likes
20

I’ve gone ahead and made a first round of changes here so we can start to get a sense of how it feels in practice together.

I’ve also updated the default sidebar categories, but haven’t applied them for everyone, so if you want to try out setting your sidebar to the new defaults, you can do this:

  1. Click the edit pencil next to “Categories” in your sidebar
  2. Choose “Reset to defaults” in the bottom right of the modal
  3. Adjust as desired
  4. Click :Save Changes"

Screenshot 2026-02-25 at 5.47.16 AM
Screenshot 2026-02-25 at 5.47.16 AM809×1009 73.8 KB

Please share any feedback you have here over the coming week or so:

2 Likes