Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Documentation Journey
Search
ericholscher
November 08, 2013
Technology
1
120
Documentation Journey
A talk about Documentation I gave a PDXNode in November 2013
ericholscher
November 08, 2013
Tweet
Share
More Decks by ericholscher
See All by ericholscher
Introduction to Django Channels - ConFoo Vancouver 2016
ericholscher
0
230
Understanding Documentation Systems - ConFoo Vancouver 2016
ericholscher
0
290
Python Documentation: Past, Present, & Future
ericholscher
3
340
Understanding Documentation Systems
ericholscher
1
270
Documentation as Empathy
ericholscher
1
250
Introduction to Sphinx & Read the Docs Djangocon 2015
ericholscher
0
170
Announcing Read the Docs for Business
ericholscher
1
230
Write the Docs NA 2014 Introduction
ericholscher
0
150
Introduction to Sphinx & Read the Docs
ericholscher
3
500
Other Decks in Technology
See All in Technology
生成AI時代 文字コードを学ぶ意義を見出せるか?
hrsued
1
750
AWS テクニカルサポートとエンドカスタマーの中間地点から見えるより良いサポートの活用方法
kazzpapa3
3
630
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
230
タイミーのデータモデリング事例と今後のチャレンジ
ttccddtoki
6
2.1k
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
380
B2C&B2B&社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理
belongadmin
1
3.4k
Core Audio tapを使ったリアルタイム音声処理のお話
yuta0306
0
160
CursorによるPMO業務の代替 / Automating PMO Tasks with Cursor
motoyoshi_kakaku
2
850
rubygem開発で鍛える設計力
joker1007
3
340
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
kawauso
2
4.9k
KubeCon + CloudNativeCon Japan 2025 Recap Opening & Choose Your Own Adventureシリーズまとめ
mmmatsuda
0
240
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
2
7.1k
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
How STYLIGHT went responsive
nonsquared
100
5.6k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
125
52k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
Scaling GitHub
holman
459
140k
Raft: Consensus for Rubyists
vanstee
140
7k
Adopting Sorbet at Scale
ufuk
77
9.4k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Speed Design
sergeychernyshev
32
1k
Building Adaptive Systems
keathley
43
2.6k
Transcript
Eric Holscher PDX Node Nov ‘13 Documentation Journey
What This Talk Is • High level overview of how
to think about documentation • Why documentation matters • Overview of my thoughts on doing docs well • Discussion around Node community documentation
What this talk isn’t • Telling you how to write
docs • User/Product documentation
Disclaimer • I don’t know a lot about Node
Who am I • Maintainer of Read the Docs •
Co-Organizer of Write the Docs
Why Write Docs
You will be using your code in 6 months
You want people to use your code
You want people to help out
It makes your code better
You want a (better) community
You want to be a better writer
Documentation as Empathy
outreach • We want more people to code • How
do I become a programmer? • Having good documentation allows people to learn how to program
Internationalization • Documentation is much more accessible for non-native speakers
• Text is most easily translated into other languages
Other Audiences • Each tool is unique • People want
to use your code, so make it easy for them, whoever they are.
Good Documentation
Types of Documentation • Tutorials • Overviews and Topical Guides
• Reference Material
Tutorials • Be quick • Be easy (but not too
easy) • Give a “feel” for your project
Tutorials • Great for people who are new to your
project • Should aim to delight or scare
Topical Guides • High level concepts • Vertical component •
Comprehensive
Topical Guides • Great for people who don’t know your
project space well • Give you the “why” • The “meat” of your docs
Reference • Provide lists of classes and modules • Organize
by hand, generate to keep up to date
Reference • Great for users who already use your so
ware • Give you the “how”
Official • Good documentation comes from the project • Must
be constantly updated with code changes • Put process in place
If you only have reference docs, your docs are broken
Current Tools
README’s • Great for small projects • Provide a very
specific thing • Basically a “getting started” doc
Blog Posts • Quickly goes out of date • Stack
Overflow solves this problem better • Good for Topical Guides
Wiki’s • No ownership • Lower quality based on “someone
will fix it later”
Books • Free projects should have free documentation • Books
are effectively always out of date
Reference • Generally provided by automated tools • http://jsdoc.info/
State of the Art • Folder Full of Markdown •
Served on GitHub • “Website”
Missing bits
Missing Bits • Overview of ecosystem/project • Central Repository for
Prose Documentation • Standard Tools
Standard Tooling • Need a common format • Where you
go a er a folder full of markdown • Not “build a custom website”
Documentation Focused • Not a website builder • Needs primitives
specific to documentation
Tooling Benefits • Search • Discovery • Design • Interoperability
• Platform (API)
Easy and Obvious • New users need an easy way
to get started • There needs to be an obvious path towards a good solution
Path Forward
Community • Docs are a community problem • You need
to expect them and complain if they don’t exist
Young • You can help shape what the world looks
like • Derived projects will follow your lead
Conclusion • Good documentation is hard work • Documentation acts
as outreach • Work to improve tools, to make writing documentation easier
Reference Links • jacobian.org/writing/great- documentation/ • docs.writethedocs.org/en/latest/ writing/beginners-guide-to-docs/
Thanks • @ericholscher •
[email protected]
• Questions?