we can roughly divide readers into three groups: users, administrators, and developers.

When people say, "I was writing all day," they don't mean they were intermittently typing for eight straight hours. They mean they spent the entire day engaged in the writing process. And a big part of that process is installing, configuring, and testing software—in other words, learning.

some amount of duplication is always going to occur. But for the most part, linking liberally, arranging topics in a sensible way, and trying to adhere to a single source model is a good idea.

Making proper use of links lets us attain a sort of Holy Grail in technical writing: single sourcing.

How does the number of documentation bugs compare to the number of emails to customer support? Do the most-used features of the product correlate with the most-visited pages of the documentation?

Wherever you store your documentation, place a file named README.md in the root of the repository (or in ./docs). This Markdown file should include: A quick summary of the product being documented Instructions on how to build the documentation locally Instructions on how to contribute

How do I install the product? What are the basic configuration options, if any?

Learn everything about a subject. Write down exactly what an audience needs to know and no more. Make the content beautiful, discoverable, scannable, and searchable. Consider everything a draft, and iterate relentlessly. Make contribution simple.

Where can I acquire this product? If there are multiple distribution packages, which should I choose and why?