Skip to content

Latest commit

 

History

History
102 lines (64 loc) · 3.06 KB

documentation.md

File metadata and controls

102 lines (64 loc) · 3.06 KB

Table of Contents

Documentation

General Best Practices

People read documentation in order to achieve a goal. Whenever you write a new piece you should keep their goal in mind.

For instance, you're currently reading this document. What is your goal? Maybe you want to improve the documentation of your own project, or perhaps you've been told this is an awesome document and your goal is simply to enjoy reading a beautiful text of astonishing beauty.

On the other hand I know you're a developer, so there's no point explaining what source code is. That would seem patronizing or a waste of time.

I also know that most of us don't speak English as a first language. Unnecessarily complicated words or sentences are then obstacles to our communication.

Finally, I know you're a diverse group. Among the readers of this document you'll find people from everywhere on the gender spectrum, different races, and different sensibilities. I do not wish to alienate any of them, so I need to be careful with the words I choose.

All of these concrete examples can be boiled down to the following best practices.

State A Clear Goal

Define A Scope

Keep It Simple

Don't Alienate The Reader

Keep Accessibility In Mind

Arbitrary Choices And Consistency

Documentation Artifacts

README.md

TL;DR:

CONTRIBUTING.md

TL;DR:

Reference Material

TL;DR:

  • Audience: Users of the project.
  • Content: List of all of the features of the project with full information on arguments, flags, and others.
  • Example: https://docs.angularjs.org/api

Release Notes

TL;DR:

  • Audience: Contributors and users of the project.
  • Content: New features, bug fixes, and other relevant changes since the previous version was released.
  • Example: https://golang.org/doc/go1.9

Guides/Tutorials

TL;DR:

Code of Conduct

TL;DR:

Issue Templates

Other Pieces Of Documentation

Resources