coder/docs/about/contributing/documentation.md

# Documentation

This style guide is primarily for use with authoring documentation.

## General guidelines

- Use sentence case, even in titles (do not punctuate the title, though)
- Use the second person
- Use the active voice
- Use plural nouns and pronouns (_they_, _their_, or _them_), especially when
  the specific number is uncertain (i.e., "Set up your environments" even though
  you don't know if the user will have one or many environments)
- When writing documentation titles, use the noun form, not the gerund form
  (e.g., "Environment Management" instead of "Managing Environments")
- Context matters when you decide whether to capitalize something or not. For
  example,
  ["A Job creates one or more Pods..."](https://kubernetes.io/docs/concepts/workloads/controllers/job/)
  is correct when writing about Kubernetes. However, in other contexts, neither
  _job_ nor _pods_ would be capitalized. Please follow the conventions set forth
  by the relevant companies and open source communities.

## Third-party references

If you have questions that aren't explicitly covered by this guide, consult the
following third-party references:

| **Type of guidance** | **Third-party reference**                                                              |
|----------------------|----------------------------------------------------------------------------------------|
| Spelling             | [Merriam-Webster.com](https://www.merriam-webster.com/)                                |
| Style - nontechnical | [The Chicago Manual of Style](https://www.chicagomanualofstyle.org/home.html)          |
| Style - technical    | [Microsoft Writing Style Guide](https://docs.microsoft.com/en-us/style-guide/welcome/) |

## Tools

This repository runs [Vale](https://vale.sh/) on `docs/` as part of CI to enforce prose style.
The configuration is the repo-root `.vale.ini`, and the curated rule set is documented in [`docs/.style/style-guide/`](https://github.com/coder/coder/tree/main/docs/.style/style-guide).
Run the same checks locally with `make lint/prose`.
Vale runs in advisory mode in this iteration: warnings surface as inline PR annotations, but they don't block the build.

The following external tools can also help when drafting. Take their
suggestions with a grain of salt because they aren't tuned for Coder's
voice or product names:

- [alex.js](https://alexjs.com/)
- [Grammarly](https://app.grammarly.com/)
- [Hemingway Editor](https://hemingwayapp.com/)

## How to format text

Below summarizes the text-formatting conventions you should follow.

### Bold

Use **bold** formatting when referring to UI elements.

### Italics

Use _italics_ for:

- Parameter names
- Mathematical and version variables

### Code font

Use _code font_ for:

- User text input
- Command-line utility names
- DNS record types
- Environment variable names (e.g., `PATH`)
- Filenames, filename extensions, and paths
- Folders and directories
- HTTP verbs, status codes, and content-type values
- Placeholder variables (see [Placeholders in angle brackets](#placeholders-in-angle-brackets))

Use _code blocks_ for code samples and other blocks of code. Be sure to indicate
the language your using to apply the proper syntax highlighting.

```txt
This is a codeblock.
```

For code that you want users to enter via a command-line interface, use
`console`, not `bash`.

### Placeholders in angle brackets

Placeholder values written in angle brackets **must** be wrapped in backticks so
they render as inline code. The documentation site renders Markdown as HTML, so
an unwrapped placeholder such as `<organization-name>` is parsed as an unknown
HTML tag and stripped out of the page, so readers never see it.

This applies wherever the text becomes documentation, including the Go CLI help
strings and Swagger annotations that generate the CLI and API reference.

```text
# Correct: wrap the placeholder in backticks
Structured as: `<organization-name>/<team-slug>`.

# Incorrect: the placeholder renders as "Structured as: /."
Structured as: <organization-name>/<team-slug>.
```

### Punctuation

Do not use the ampersand (&) as a shorthand for _and_ unless you're referring to
a UI element or the name of something that uses _&_.

You can use the symbol `~` in place of the word _approximately_.

### UI elements

When referring to UI elements, including the names for buttons, menus, dialogs,
and anything that has a name visible to the user, use bold font.

**Example:** On the **Environment Overview** page, click **Configure SSH**.

Don't use code font for UI elements unless it is rendered based on previously
entered text. For example, if you tell the user to provide the environment name
as `myEnvironment`, then use both bold and cold font when referring to the name.

**Example**: Click **`myEnvironment`**.

When writing out instructions that involve UI elements, both of the following
options are acceptable:

- Go to **Manage** > **Users**.
- In the **Manage** menu, click **Users**.

## Product-specific references

Below summarizes the guidelines regarding how Coder terms should be used.

### Capitalized terms

The only Coder-specific terms that should be capitalized are the names of
products (e.g., Coder).

The exception is **code-server**, which is always lowercase. If it appears at
the beginning of the sentence, rewrite the sentence to avoid this usage.

### Uncapitalized terms

In general, we do not capitalize the names of features (unless the situation
calls for it, such as the word appearing at the beginning of a sentence):

- account dormancy
- audit logs
- autostart
- command-line interface
- dev URLs
- environment
- image
- metrics
- organizations
- progressive web app
- registries
- single sign-on
- telemetry
- workspace
- workspace providers
- workspaces as code

We also do not capitalize the names of user roles:

- auditor
- member
- site admin
- site manager

## Standardized spellings

- WiFi