FOSS DOCS 101 (keep it simple, present!)
summary
Practical prescriptions: break giant XML guides into topic files so contributors edit single modules; reorganize OpenStack-style long getting‑started sections rather than rewrite them; expose docs in the same repo and CI so every commit runs broken links check and tests code examples; use role-based help (users / admins / developers) and a one‑page contribution guide plus reusable README templates; run doc sprints, continuous deployment of docs, and basic automated style checks like Hemingway and a Sublime plugin.
AI-written summary · about
chapters (35)
- 0:00Intro
- 0:31Mikeys background
- 1:16Help desk
- 1:33Why documentation
- 2:17How documentation used to be
- 2:55How to help a software project
- 3:33Pros
- 4:27Join the Docs Club
- 5:04Content Strategy
- 5:32Users
- 6:32What do they want
- 7:25When do they need it
- 8:30Error messages
- 9:42Why
- 12:02Bugs
- 12:24Who are you
- 12:45Administrator
- 13:12Developers
- 13:24Arch Linux Wiki
- 14:51Red Hat
- 15:43Working on new guides
- 16:29DevOps for docs
- 17:23Unified tool chain
- 19:20Continuous integration
- 20:36Content curation
- 24:27Community engagement
- 25:40Outreach efforts
- 26:38Example
- 27:42Templates
- 28:35Collaboration
- 29:52Documentation conferences
- 32:12Everyone can care
- 32:48QA Questions
- 37:42Organizational Position
- 39:55When to hire a writer
related talks
50mOpen Source Survival Guide
56mEffective Documentation: The Key to Open Source Growth
36mOSS Docs and How to Scale Them: Common Themes From the CNCF Ecosystem
45mDocs That Scale: Strategies for Sustainable Documentation in Open Source Projects
32mBridge the Gap To OSS Adoption With Documentation: A Kubernetes Story
34mFOSS like a Boss!
33mOSS Documentation Workshop
35mHelping Your Community Contribute to Developer Documentation