Contributing to Documentation
Everyone can and should contribute to our documentation! Here's how.
Why Contribute?
- Share knowledge - Help others learn
- Save time - Document it once, reference forever
- Reduce confusion - Clear docs = fewer questions
- Onboard faster - New folks get up to speed quickly
- Build culture - Docs reflect how we work
Quick Start
Fixing a Typo (2 minutes)
- Click "Edit" on any page
- Make your change
- Submit PR with description
- Merge after approval
Adding New Content (10 minutes)
- Create new
.mdfile in appropriate folder - Write in Markdown
- Update navigation in
mkdocs.yml - Submit PR
- Preview deploy and merge
What to Document
Always Document
- ✅ Decisions - Why we chose X over Y
- ✅ Processes - How we do things
- ✅ Onboarding - What new people need
- ✅ Troubleshooting - Common problems & solutions
- ✅ Architecture - How systems work
- ✅ APIs - How to integrate
Don't Document
- ❌ Sensitive data - Passwords, keys, PII
- ❌ Temporary info - Use Slack instead
- ❌ Personal opinions - Keep it factual
- ❌ External docs - Link, don't copy
- ❌ Work in progress - Wait until stable
How to Contribute
Method 1: GitHub Web UI (Easy)
- Navigate to file on GitHub
- Click pencil icon to edit
- Make changes in browser
- Write commit message
- Create pull request
Method 2: Local Development
# Clone repo
git clone git@github.com:yourcompany/docs.git
cd docs
# Create branch
git checkout -b update-deployment-docs
# Make changes
code docs/engineering/deployment.md
# Preview locally
pip install mkdocs-material
mkdocs serve
# View at http://localhost:8000
# Commit and push
git add .
git commit -m "docs: update deployment guide"
git push origin update-deployment-docs
# Create PR on GitHub
Writing Style Guide
Principles
- Clear over clever - Simple language
- Practical over theoretical - Real examples
- Scannable - Headers, bullets, tables
- Inclusive - Welcoming to all
- Up-to-date - Regular reviews
Voice & Tone
- Friendly but professional
- Direct but not blunt
- Helpful but not condescending
- Confident but not arrogant
Structure
# Clear Title
Brief introduction paragraph explaining what and why.
## Main Section
### Subsection
Content with:
- Bullet points for lists
- **Bold** for emphasis
- `code` for technical terms
## Examples
Show real examples people can use.
## Next Steps
What should reader do next?
Formatting Guidelines
Headers
Lists
Code Blocks
Tables
Admonitions
Writing Tips
Do's ✅
- Use present tense
- Write short sentences
- Include examples
- Add visuals when helpful
- Link to related docs
- Test your instructions
Don'ts ❌
- Don't assume knowledge
- Don't use jargon without explaining
- Don't duplicate existing docs
- Don't write walls of text
- Don't forget to proofread
Pull Request Process
Before Submitting
- Spell check - No typos
- Preview locally - Looks good
- Links work - Test all links
- Makes sense - Would a new person understand?
- Adds value - Improves on what exists
PR Template
## What Changed
Brief description of changes
## Why
Problem this solves or value it adds
## Type of Change
- [ ] Fix typo
- [ ] Add new documentation
- [ ] Update existing docs
- [ ] Restructure/reorganize
## Checklist
- [ ] Previewed locally
- [ ] Links tested
- [ ] Spell checked
- [ ] Updated navigation if needed
Review Process
- Auto-checks run (links, spelling)
- Preview deployment created
- Reviewer assigned (usually automatic)
- Feedback addressed if any
- Merged to main
- Auto-deployed to site
Maintenance
Regular Reviews
- Monthly: Check for outdated info
- Quarterly: Review structure
- Yearly: Major reorganization
Outdated Content
Found something outdated?
- Quick fix: Update it yourself
- Need help: Create an issue
- Not sure: Ask in #docs
Broken Links
- Check weekly with automated tools
- Fix immediately when found
- Update or remove dead links
Documentation Standards
File Naming
Front Matter (Optional)
Images
- Use descriptive alt text - Optimize image size - Prefer SVG for diagramsCommon Patterns
How-To Guide
# How to [Task]
## Prerequisites
What you need before starting
## Steps
1. First step
2. Second step
3. Third step
## Verification
How to know it worked
## Troubleshooting
Common issues and fixes
Reference Doc
# [Feature] Reference
## Overview
What this is
## Configuration
Available options
## Examples
Common use cases
## API
Detailed specifications
Explanation
# Understanding [Concept]
## What is it?
Definition and purpose
## Why use it?
Benefits and use cases
## How it works
Technical explanation
## Best practices
Recommended approaches
Getting Help
Questions?
- Content: Ask in #docs
- Technical: Ask in #engineering
- Process: Ask in #operations
Learning Resources
Recognition
We appreciate documentation contributions!
- Monthly shoutouts for contributors
- Documentation champion award
- It counts in performance reviews
Quick Wins
Want to contribute but not sure where? Try these:
- Fix a typo you noticed
- Add an example to existing docs
- Update screenshots that are outdated
- Improve unclear explanations
- Document something you just learned
Remember
"The best documentation is the one that exists."
Perfect is the enemy of good. Your contribution doesn't have to be perfect - others can help improve it. The important thing is to share knowledge!
Start small, contribute often, and help us build amazing documentation together! 📝