No content

Jonathan Reinink Software developer from Canada. Been writing PHP for over 15 years. Marketing agency for over a decade. Started contract development this year. I <3 open source. 

No content

I love documentation. 

I enjoy the branding and marketing aspect of documentation. 

I enjoy the teaching aspect of documentation. 

I enjoy the learning aspect to documentation. 

Good docs are vital to the success of libraries, frameworks, languages and technical services. 

Developers will give something the time of day, if it's clear you have. 

Myths of documentation. 

Documentation myth #1: "Read the code" is an acceptable answer to "Where are the docs?" 

Documentation myth #2: "Auto-generated API docs are good enough.” 

— Jacob Kaplan-Moss
 (Core contributor to Django) “Auto-generated documentation is almost worthless. At best it’s a slightly improved version of simply browsing through the source, but most of the time it’s easier just to read the source than to navigate the bullshit that these autodoc tools produce…there’s no substitute for documentation written, organized, and edited by hand.” 

Documentation myth #3: "All you need a README file.” 

Documentation myth #4: "Documentation should be easy.” 

“Tests are hard so we practice to get better. Docs are hard… so we don't write any and complain.” Steve Klabnik, Senior Technical Writer (Maintainer of the official Rust documentation) 

“The difference between excellent docs and adequate docs is massive, and takes a lot of work. But going from bad docs to adequate docs is totally achievable.” Steve Klabnik, Senior Technical Writer (Maintainer of the official Rust documentation) 

The purpose of documentation. 

“The purpose of technical documentation is to take someone who has never seen your project, teach them to be an expert user of it, and support them once they become an expert.” — Steve Losh 

“The purpose of technical documentation is to take someone who has never seen your project, teach them to be an expert user of it, and support them once they become an expert.” — Steve Losh 

Must read article: Teach, Don't Tell stevelosh.com/blog/2013/09/teach-dont-tell/ By Steve Losh 

The Anatomy of Good Documentation 1. The pitch 2. The example 3. The guides 4. The reference 

1. The pitch 

The elevator speech. 

Will it save me time? Will it take more time, but be more stable in exchange? Does it offer some special features I can’t live without? Is it just plain fun? 

For bonus points, you can also mention why someone might want to not use your project. 

Not acceptable: “This package is a port from the Ruby X package.” 

What license the project uses. Where the bug tracker is. Who the author is. Where the source code is. How many times it’s been downloaded. 

2. The minimum viable example 

The minimum viable example lets your prospective user get some paint on the canvas. 

No content

No content

3. The guides 

Have a guide for every topic that you feel needs to be covered. 

Don’t be afraid to write. 

You should have a table of contents that lists each section of the guides. 

Be liberal with your use of sub titles. 

Include lots of examples. 

4. The reference 

Keep a change log. 

Show notable changes that have been made between releases. 

Consider following the Keep a CHANGELOG format, see keepachangelog.com. 

No content

{% for release in site.github.releases %} ## [{{ release.name }}]({{ release.html_url }}) - {{ release.published_at | date: "%Y-%m-%d" }} {{ release.body | markdownify }} {% endfor %} 

Make sure your API docs are actually useful. 

Welcome contributions. 

Putting it all together. 

The ideal layout. 

Project Name your tagline goes here Topic Page name Page name Page name Page name Topic Page name Page name Page name Page name Topic Page name Page name Page name Page name Page name Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut Sub title Search… 1.0.0 

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

Project Name your tagline goes here Topic Page name Page name Page name Page name Topic Page name Page name Page name Page name Topic Page name Page name Page name Page name Page name Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut Sub title Search… 1.0.0 

The design of your docs matters. 

Choose a better font. Museo Sans Open Sans Source Sans Pro Droid Sans 

Use a nice colour scheme. 

No content

Give content space. 

Use syntax highlighting. 

No content

Consider adding a search functionality. 

No content

No content

Include a link where corrections can be submitted. 

Install Google Analytics to see what content people are most interested in. 

Go forth and make awesome docs. 

Thanks! Follow me on Twitter at @reinink. Please rate this talk at joind.in/talk/f2272.