How to Set Up a Team Wiki in GitBook

Set up a GitBook organization for your company and create separate spaces for each knowledge area: Engineering, Product, Design, Operations, and Onboarding. Spaces act as self-contained wikis with their own page hierarchy, permissions, and navigation. This separation keeps the information architecture manageable and lets you set different access levels per space.

• Create the organization and invite all team members with appropriate roles
• Create 4-6 spaces covering your major knowledge domains
• Set the Engineering space to require merge requests for changes to ensure review

Within each space, create a logical page structure using GitBook's nested page feature. For the Engineering space, top-level pages might be Architecture, API Reference, Development Setup, Runbooks, and ADRs. Each top-level page contains sub-pages for specific topics. Keep the hierarchy to three levels maximum — deeper nesting makes content unfindable.

• Draft the page structure in an outline before creating pages in GitBook
• Use consistent naming patterns across spaces (Getting Started, How-To Guides, Reference, Runbooks)
• Add a 'Table of Contents' page at the root of each space that links to key entry points

Create templates for common page types: runbooks should always have a Symptoms, Cause, Fix, Prevention structure. ADRs should follow the Status, Context, Decision, Consequences format. How-to guides should have Prerequisites, Steps, Troubleshooting. Templates enforce consistency so every contributor produces pages that follow the same structure, making them scannable and trustworthy.

• Create a runbook template with sections for symptoms, diagnosis steps, fix procedure, and prevention
• Create an ADR template following the standard format with status, context, decision, and consequences
• Create a how-to template with prerequisites, numbered steps, expected outcomes, and troubleshooting

Set space-level permissions: most spaces should be readable by everyone but editable only by the relevant team. Enable GitBook's change requests feature on critical spaces so edits go through a review process before publishing. Assign a documentation owner for each space who reviews change requests and ensures content quality.

• Set the Engineering space to require change request approval before publishing
• Give all team members read access to all spaces and edit access to their own team's space
• Designate one person per space as the documentation owner responsible for review and maintenance

Connect GitBook to GitHub to enable editing wiki pages in your IDE and syncing changes via pull requests. Connect to Slack so new pages and major updates post to your team channels. Embed GitBook links in your onboarding checklist and project documentation so the wiki becomes part of existing workflows rather than an isolated destination.

• Set up GitHub Sync so the wiki content lives in a Git repository alongside your code
• Install the GitBook Slack integration to notify channels when important pages are updated
• Add GitBook links to your Slack topic, onboarding checklist, and project templates

Schedule a quarterly documentation review where each team audits their space for outdated content, missing pages, and broken links. Use GitBook's 'Last updated' metadata to identify stale pages — any page not updated in six months should be reviewed for accuracy or archived. A wiki with outdated information is worse than no wiki because it teaches people not to trust the documentation.

• Add a quarterly calendar event for documentation review with each team's documentation owner
• Create a 'Needs Review' label or page flag for content that team members notice is outdated
• Archive rather than delete outdated pages so the content is still searchable if needed