普通文本  |  72行  |  2.74 KB

# Philosophy

埏埴以為器,當其無,有器之用.

*Clay becomes pottery through craft, but it's the emptiness that makes a pot
useful.*

\- [Laozi](http://ctext.org/dictionary.pl?if=en&id=11602)

Contents:

1.  [Radical simplicity](#radical-simplicity)
1.  [Readable source text](#readable-source-text)
1.  [Minimum viable documentation](#minimum-viable-documentation)
1.  [Better is better than perfect](#better-is-better-than-perfect)

## Radical simplicity

* **Scalability and interoperability** are more important than a menagerie of
  unessential features. Scale comes from simplicity, speed, and ease.
  Interoperability comes from unadorned, digestable content.

* **Fewer distractions** make for better writing and more productive reading.

* **New features should never interfere with the simplest use case** and should
  remain invisible to users who don't need them.

* **This guide is designed for the average engineer** -- the busy,
  just-want-to-go-back-to-coding engineer. Large and complex documentation is
  possible but not the primary focus.

* **Minimizing context switching makes people happier.** Engineers should be
  able to interact with documentation using the same tools they use to read and
  write code.

## Readable source text

* **Plain text not only suffices, it is superior**. Markdown itself is not
  essential to this formula, but it is the best and most widely supported
  solution right now. HTML is generally not encouraged.

* **Content and presentation should not mingle**. It should always be possible
  to ditch the renderer and read the essential information at source. Users
  should never have to touch the presentation layer if they don't want to.

* **Portability and future-proofing leave room for the unimagined integrations
  to come**, and are best achieved by keeping the source as human-readable as
  possible.

* **Static content is better than dynamic**, because content should not depend
  on the features of any one server. However, **fresh is better than stale**. We
  strive to balance these needs.

## Minimum viable documentation

* **Docs thrive when they're treated like tests**: a necessary chore one learns
  to savor because it rewards over time.
  See [Best Practices](best_practices.md).

* **Brief and utilitarian is better than long and exhaustive**. The vast
  majority of users need only a small fraction of the author's total knowledge,
  but they need it quickly and often.

## Better is better than perfect

* **Incremental improvement is better than prolonged debate**. Patience and
  tolerance of imperfection allow projects to evolve organically.

* **Don't lick the cookie, pass the plate**. We're drowning in potentially
  impactful projects. Choose only those you can really handle and release those
  you can't.