The right tool for the job
summary
Company requires PDFs required for certification, so picks tooling that can produce reliable PDFs and HTML later. Team is one technical writer with developers comfortable with git, so decision narrows to Asciidoc over DITA and a docs-as-code now, CCMS later strategy. Migration uses migrate with pandoc to convert Word into Asciidoc, keeps presentation separate from content, and prioritizes contributors, maintenance skills, and the ability to switch platforms without losing work.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 0:44Starting docs from scratch
- 2:09Modernizing hardware docs
- 3:13Documentation tools by type
- 6:26Documentation methodologies
- 8:12Docs as code vs CCMS
- 11:18Tooling requirements questions
- 13:05Team needs evaluation
- 17:23Supporting docs tools
- 18:48Content and structure assessment
- 21:18Delivery formats and aesthetics
- 23:26Infrastructure and budget
- 25:32Time and cost of implementation
- 26:35Migrating existing docs
- 27:41Future-proofing docs setup
- 29:50Long-term tool sustainability
- 31:21Q&A
related talks
44mPushing documentation (so it doesn't hurt anymore)
23mMain Takeaways After One Year in Documentation
50mContinuous and Automated Documentation Docs As Code in Practice
46mAsciidoctor: because writing docs does not have to suck
45mOne AWS team’s move to docs as code
47mEngineering Documentation
51mDocumentation as Code (Explained to My Father)
43mPutting the “tech” in technical writer