Main Takeaways After One Year in Documentation
summary
Claim: documentation is a must‑have, not a nice‑to‑have; it must be ready 8–12 weeks before release. The team maintains 12,000 pages using a single‑source pipeline based on DITA XML, Git/GitHub and custom shell scripts, builds with the TOCbook authoring and publishing suite, runs style and spell checkers, and outputs HTML PDF and epub. The group writes installers and small tools, standardises partner papers, automates content gathering with Distillery, and proves the workflow actually scales.
AI-written summary · about
chapters (30)
- 0:00Introduction
- 0:52What is your role
- 1:12Documentation of software
- 2:20I dont need documentation
- 3:15No one reads documentation
- 4:09The importance of documentation
- 4:28Missing documentation
- 5:15Meet the Docs
- 5:46Four Pillars of Documentation
- 6:31Classic Style Documentation
- 6:53Best Practices
- 7:43Where does the content come from
- 8:18You are a superpower
- 9:05Ready to use documentation
- 10:21Behind Great Documentation
- 11:21Documentation Infrastructure
- 12:47Single Source Commissioning
- 13:12XML
- 14:02Structure Stack
- 15:17Style Sheets
- 15:48Other Steps
- 16:46Conclusion
- 17:23Technical Alliance
- 18:31Customers and Partners
- 19:25Collaboration
- 20:13Be relevant
- 20:48Be creative
- 21:28Stay in communication
- 22:11Make documentation visible
- 22:37Outro
related talks
44mPushing documentation (so it doesn't hurt anymore)
37mTaking a step back: Analysing your documentation
27mThe hidden power of information assets The role of documentation in product success
36mTo document, or not document that is the question
18mTechnical Documentation - How Can I Write Them Better and Why Should I Care?
38mThe Stuff You Don't Want to Write... Documentation
44mTesting Documentation: Why So Technical?
44mCreating a Culture of Documentation