A technical community on Discourse is not a hobby board with nicer CSS. It is a support inbox that other people can search, plus a short set of docs that staff can point at instead of retyping. The product already wants that shape: few categories, tags for version and component, an official Solved plugin, a Doc Categories plugin for a sidebar index, and Assign so a ticket-shaped topic has an owner. XenForo can do a knowledge base with page nodes and help pages. This article is the Discourse version of that job — topics and tags, not a node tree.
This is not the first-week admin wizard. Week one still applies (short category list, leave trust levels on, honest email). This is the design of a docs + support site once that week is over. It is not the member 30-day onboarding calendar and not a XenForo tickets tour. Official plugin pages (Solved, Doc Categories, Assign) plus Meta’s category/tag practice are the sources. If a setting is not on those pages, this article does not invent it.
What “technical community” means here
Write the sentence. Then pick the furniture.
| Sentence | Discourse object |
|---|---|
| “This is a question we want a durable answer to” | Topic in Support, tag for product/version, Solved when a reply is the answer |
| “This is canon we will maintain” | Topic in a Docs category, listed by Doc Categories |
| “This is a known issue with a workaround” | Docs or a solved Support topic staff keep pinned for a release |
| “This is still on fire and someone must own it” | Support topic assigned to a staff user |
| “This is something only employees should see” | Category restricted to a staff / employees group |
| “This is chatter about the project, not a ticket” | General / Meta, not Support |
| “This is a one-way release note” | Announcements, staff-create only |
If every sentence maps to “a forum named after a mood,” you are building a phpBB tree. Stop. Discourse will make that tree worse.
A technical community that works has three public rooms and one private room, then tags. More rooms are how answers hide.
Information architecture: fewer categories than your org chart
Seed a technical site like this. Rename to your product language. Do not add a category for every team.
| Category | Who creates topics | Why it exists |
|---|---|---|
| Announcements | staff only | Releases, incidents, breaking changes. Members watch it. |
| Docs | staff (and maybe TL3+ later) | Canon. Doc Categories index lives here. |
| Support | everyone who can create topics | Questions. Required tags. Solved on. Assign on. |
| General or the real name of the craft | everyone | Not a ticket. “How do you think about X.” |
| Meta / site feedback | everyone | The community, not the product |
| Staff (hidden) | staff group | Private. Create it before you need it. |
| Internal (hidden, optional) | employees group | Roadmap, customer names, pre-release. Not Support. |
That is enough. Five public-facing surfaces plus a private staff room will carry a product community for a long time. If you came from a Zendesk + Confluence + Slack triangle, resist recreating all three as twelve categories. Support is the ticket pile. Docs is the manual. Announcements is the firehose. General is how people become regulars. Internal is the room guests must never see.
Tags are the rest of the map
Cross-cutting ideas are tag groups, not child boards:
- Product / component —
api,cli,billing,auth - Version —
v2.3,v2.4,nightly(only as many as you will actually filter) - Status you will honour — if you use Solved, do not also invent a folksonomy of
answered/closed/wontfixunless staff will apply it - Platform —
ios,linux,dockerwhen that is really how people search
On Support, set a minimum number of tags (usually 1) and allow only the version or component group. Meta’s long-running advice for migrants is exactly this: required tags instead of child boards. A Support category that accepts any user-created tag becomes a junk drawer in a month.
Start with user-created tags off. You can loosen later. You cannot easily unteach a folksonomy.
Do not build a tag for every old Zendesk form field. Tags should answer “what is this about besides Support,” not “what was the ticket metadata id.”
Category descriptions are topics
On Discourse a category description is a topic, not a one-line phpBB forum desc. Write two sentences a new user can act on.
- Support: “Ask one question per topic. Pick a version tag. Mark a reply as the solution when it unblocks you. Search Docs first.”
- Docs: “Staff-maintained. If something is wrong, reply or open a Support topic — do not start a second manual.”
- Announcements: “Staff only. Watch this if you run the software in production.”
Then pin a how to get help topic in Support that repeats the TL0 image cap (one embedded image until they leave the sandbox) so intro posts do not die on screenshots. That cap is a default, not a personal insult.
Solved: the official accepted-answer plugin
Solved is an official plugin. Hosted: listed on Pro, Business, and Enterprise. Self-host: the plugin directory / Meta topic is the install path (rebuild after you add it — see the hosting cookbook). This article names the controls the official plugin page names. It does not invent extra ones.
What it does
- A topic can have one accepted solution.
- Solved topics show a check on the topic list.
- The solution is automatically displayed at the bottom of the first post, so the next reader does not scroll forty replies to find the answer.
- Public marketing and Meta both treat this as the Q&A loop: great answer → accept it.
How you turn it on (official page)
- Enable the plugin in site settings.
- Either:
- enable solved per category — category page → edit → settings tab → “Allow topic owner and staff to mark a reply as the solution”, or
- enable “allow solved on all topics” globally.
- Topic owners then see the solved control next to the like count. Staff can mark a post solved from the expanded post actions.
For a technical community: on for Support. Off for Announcements, Docs, General, and Staff. Docs are canon, not a question. Announcements are not “solved.” General is a conversation. If you turn Solved on everywhere, people will “solve” a design thread and you will spend a year explaining why that check mark is meaningless.
The ?solved=yes filter
The official / planned-topics brief for this site is explicit: Solved topics are filterable with ?solved=yes. Use that in staff links, in the how-to-get-help topic, and in any public “known answers” bookmark you give customers. Combine it with a category and a tag when you are writing a weekly digest: Support + billing + solved is a page you can hand a new hire.
Do not invent other query params. If your site’s UI also offers Unsolved / All filters in the category, use those labels as the UI shows them.
Accepted-answer ROI (how to read it, not a fake benchmark)
Solved is not gamification. It is search hygiene and staff time.
What to look at on your site, after a month, not against a number this article made up:
- Share of Support topics that become solved. If it is near zero, owners do not know the button exists, or staff never accept on behalf of a silent OP. Fix the how-to topic and the staff habit before you install another plugin.
- Time-to-first-reply versus time-to-solved. A fast first reply that is “we are looking” is not an answer. Solved tells you whether the thread actually closed the loop.
- Repeat questions. If the same tag keeps producing new unsolved topics, the Docs category is missing a page, or the solution is buried in a 90-post thread nobody accepted.
- Staff-accepted versus OP-accepted. Both are valid. A lot of staff-accepted and zero OP-accepted usually means your users are drive-by and staff are doing the hygiene. That can be fine. It is a staffing fact.
None of those need a BI tool on day one. Latest + the solved filter + a weekly staff note is enough to see whether the loop exists.
Doc Categories: a sidebar index, not a second wiki product
Doc Categories is an official plugin. Hosted: listed on Business and Enterprise (not the Pro row). Self-host: plugin directory. The official page’s job description is short, and this article will stay inside it:
- Organize documentation topics into categories.
- Each category may be assigned an index containing a list of links to documentation topics.
- The index is displayed in the native sidebar when a user is browsing that category.
That is the whole official how-to. Do not invent a “Doc Categories settings” tour this page does not print.
How to use it without building a wiki you will abandon
- One Docs category (or one per product, not per department).
- Topics in that category are canon. Staff edit the original post. Close or wiki-flag if your site offers that control — use the UI you have; do not invent a workflow from Confluence.
- The index is a curated list, not an automatic dump of every topic anyone posted in Docs. If the index is a firehose, you built Support inside Docs.
- Link from Support solutions to Docs when an answer has stabilized. Do not copy the full manual into the solution; onebox or link the docs topic.
- Permissions: guests should read Docs if you want Google and customers to use them. Creating docs topics stays with staff (or a writers group).
If you are on hosted Pro, Doc Categories is not on that plan’s public plugin row. You can still run a Docs category as ordinary topics plus a pinned index topic. That is less pretty. It works. Do not upgrade to Business solely because a sidebar looked nice in a screenshot. Upgrade if the docs are the product surface.
XenForo people will want page nodes. Discourse does not have page nodes. A docs topic that staff maintain is the page. Doc Categories is the table of contents. If you need a marketing homepage, that is a theme or a site in front of Discourse, not a twelfth category.
Assign: ownership without pretending you have Zendesk
Assign is an official plugin. Hosted: Business and Enterprise. Official page, used here without extra knobs:
- Staff can assign topics to staff (including themselves).
- Assignments default to private — only staff see them.
- A tag-like annotation on the topic list and topic header shows the assigned username.
- Each user gets a list of topics assigned to them.
- There is an Assign button at the end of each topic (public and private) once the plugin is enabled in site settings.
- Automatic options the page names: assign by staff mention, and assign when the post matches a regular expression.
- You can configure assignments to be public so regular users see which staff member owns the topic.
A support habit that does not require a second product
- New Support topics that are not obvious FAQ material get assigned or they sit in Latest until they rot. Pick one. Assigned-to-nobody is how SLA fantasies die.
- Assign to a human, not to a fake “support” user, unless you have a rota account everyone checks. The per-user assigned list is the point.
- Keep assignments private until you have a reason to show customers a name. Public assignment is a transparency choice and a pile-on risk.
- When a topic is solved, unassign. An assigned+solved queue is how people stop trusting the list.
- Mentions as auto-assign: useful if staff already type
@sarawhen they hand off. Dangerous if customers@every staff name they can find. Read the setting description in the admin UI before you enable it. This article will not invent the exact site-setting key beyond what the plugin page already said.
Assign is not a helpdesk. There is no official SLA clock in the plugin page. If you need clocks, first-response metrics, and customer fields, you are looking at Zendesk (there is an official Zendesk plugin on the Business list) or at staying honest: Discourse is the searchable public room, the helpdesk is elsewhere. Many technical communities need only Assign + Solved.
Internal categories and the permission mistake that locks everyone out
Group-restricted categories are how you keep customer names, pre-release builds, and staff arguments off the public internet.
A working split:
| Category | See | Create / reply |
|---|---|---|
| Announcements | everyone (or logged-in) | staff |
| Docs | everyone | staff / writers group |
| Support | everyone | everyone who can post |
| General | everyone | everyone who can post |
| Staff | staff group |
staff |
| Internal | employees (or customers-vip) |
that group |
Discourse category security is a group table, not XenForo’s Never/Yes/No tree. Trust levels are the ladder, not the wall. Extra groups are for access and @mentions.
Common new-admin failure (from the research notebook, still true on a technical site): adding Admin + Moderator + TL1 + TL2 + TL3 + TL4 redundantly to a category because it feels thorough. Hierarchy plus the Staff group already cover this. The failure mode is “not permitted to view” for people who should see it. Add the groups that mean access. Do not add the entire ladder “to be safe.”
Other failures that hurt technical communities specifically:
- Internal accidentally public. A guest can open
/c/internal. Check in a private window before you paste a customer hostname. - Support private “to reduce noise.” Then Google cannot help the next person and every question is a new ticket. If the product is public, Support should be public unless the question itself is a secret.
- Staff talking in Support instead of Staff. Customers read tone. Use the private room.
Create the Staff category before the first incident. The first incident is the wrong time to learn category security.
Trust levels and SSO: staff must not start as TL0
A technical community that invites the company’s engineers as ordinary signups will spend a week watching them bounce off the one-image TL0 cap and the “you cannot flag yet” sandbox. That is the product working. It is also a ridiculous first day for the people you hired to answer tickets.
What you want on day one for employees:
- They can see Internal and Staff.
- They can post images and links like a normal colleague.
- A few of them can help moderate (TL4 or the official moderator grant) without waiting for a 100-day Regular window.
- They do not all become admin.
Groups can grant a minimum trust level
Discourse groups can grant a minimum trust level. That is why some users sit higher than their activity explains. Put employees in an employees group that grants at least TL2 (full member toolbox: images, flags, 30-day edit). Put the on-duty support rotation in a group that grants TL3 if you want Regular tools (create tags, heavier flags, edit_all_topic_groups default) without waiting for the rolling window.
TL4 is not an activity trophy. Meta is explicit: staff promote people they trust to help moderate — staff/manual or SSO, not auto. Do not hand TL4 to the whole engineering org as a welcome gift. TL4 is junior moderation (pin, timers, split/merge, unlimited own-post edit, edit_all_post_groups default). That is a grant, not a sticker.
DiscourseConnect / SSO mapping
If a parent site already owns identity, official DiscourseConnect (the current name for official SSO) can send more than a username. The official Meta topic names payload fields that matter here — use these, do not invent others:
admin/moderatorbooleansgroups, oradd_groups/remove_groupsexternal_id, verifiedemail
Hosted: custom OIDC/OAuth2 and DiscourseConnect sit on the Business row of the public pricing grid (re-check discourse.org/pricing). Self-host: DiscourseConnect is core; you still have to implement the other side correctly. Misconfigured SSO is how you lock everyone out of a forum that has no posts yet. The beginner’s guide’s rule still stands: if you do not already have a live identity provider, do not start SSO in week one.
A sane day-one mapping:
| Parent role | Discourse group | Minimum TL / extra |
|---|---|---|
| Employee | employees |
TL2 minimum |
| Support / docs writer | support-staff |
TL3 minimum; Assign-visible |
| Community moderator | moderators or official moderator |
TL4 or moderator boolean — pick one model and write it down |
| Forum admin | admins |
admin=true for a tiny set |
Use add_groups if you do not want SSO to wipe groups people earned on the forum. Use full groups override only if the parent directory is the source of truth and you understand you will remove people when the parent says so.
Lock individual accounts if you must (admins can set a level and lock it so automation cannot move them). Prefer group minimums so you are not clicking fifty user pages.
Invited users already default to TL1. That is enough for external experts you trust but do not employ. It is not enough for the people who must paste logs on day one — invite plus a group, or SSO.
Onboarding a technical member (not the 30-day seed calendar)
The seed first 30 days article is a member calendar after join, written for XF/IPS-shaped boards. Do not rewrite it here. For a Discourse technical site, the first hour is narrower:
- They can log in (Discourse ID, social, local mail, or SSO — one story, written in Docs).
- They can read Docs without an account if the product is public.
- The Support composer tells them: one question, one version tag, search first.
- TL0 users know they can leave the sandbox by reading (enter topics, spend time — exact counts are site settings; see Meta’s Trust Level Permissions Reference). They do not need to post to become TL1.
- A staff reply happens while the question is still on the first screen of Latest.
If you skip SMTP, say so in Docs: “Login is via Discourse ID / social; we will add email digests when mail is configured.” Do not promise mailing-list mode you cannot deliver. Inbox-driven support communities should not skip SMTP — the hosting cookbook is the ops half of that sentence.
A week-two staff checklist (the product, not the wizard)
Information architecture
- Announcements / Docs / Support / General / Meta / Staff (+ Internal if you need it)
- Support requires at least one tag from a closed group
- User-created tags off
- Each category has a two-sentence description topic
Plugins (only what this job needs)
- Solved on Support only; you have clicked
?solved=yesand it shows what you expect - Doc Categories index on Docs or a pinned index topic if you are not on Business
- Assign enabled; assignments private; staff know the button exists
- You did not install a plugin shopping list “for later”
People
- Employees land in a group with a TL2+ minimum (SSO or manual)
- TL4 / moderator grants are a named list, not “all engineers”
- Staff category restricted to staff; verified in a private window
- How-to-get-help topic mentions the TL0 one-image cap
Habits
- Unassigned Support topics have an owner within a day you can actually staff
- Solved topics get unassigned
- Stable answers become Docs links
- Nobody is using Support as Slack
What not to do
- Do not clone the org chart as categories. Tags exist.
- Do not turn off the TL0 sandbox because an engineer complained on day one. Put the engineer in a group.
- Do not enable Solved globally so a Meta thread can be “accepted.”
- Do not invent Doc Categories settings. The official page gave you an index in the sidebar.
- Do not treat Assign as a full helpdesk SLA product.
- Do not add Admin+Mod+every trust level to category security.
- Do not hide Support from guests if you want the community to reduce tickets over time.
- Do not start SSO because it is fashionable. Start it because a parent directory already exists.
- Do not rebuild a XenForo page-node tree. One Docs category is a manual.
Takeaways
- A technical Discourse is few categories + required tags + Solved + (optional) Doc Categories + Assign, not an 80-node support tree.
- Solved (hosted Pro+) is per-category or global; use it on Support; filter with
?solved=yes. The ROI is search hygiene and fewer repeat questions, not a leaderboard. - Doc Categories (hosted Business+) is a sidebar index of documentation topics. Without it, a pinned index topic still works.
- Assign (hosted Business+) gives staff an owner and a personal queue. Keep it private until you have a reason. Unassign when solved.
- Internal and Staff categories are group walls. Trust levels are the ladder. Do not stack the entire ladder into security tables.
- Map employees to groups that grant TL2/TL3 on day one. TL4 is staff/manual or SSO, not a welcome badge.
- Week-one Discourse admin is still the beginner’s guide. This article is the support-and-docs shape you put on top of it.
If Support has required tags, a solution people can find, a docs index staff actually maintain, and employees who are not stuck at one image, you have a technical community. Everything after that is answering the next question before it is asked twice.