For information about how to write technical documentation, we suggest reviewing the content of the [Google Technical Writing courses](https://developers.google.com/tech-writing).
The *Documentation style guide* is a living document. Add to it whenever a style decision is made or a question is answered regarding style, grammar, or word choice.
For all items not covered in this guide, refer to the [Microsoft Style Guide](https://docs.microsoft.com/en-us/style-guide/welcome/) and the [Chicago Manual of Style](https://www.chicagomanualofstyle.org/home.html).
This section provides guidelines on how to avoid using charged language in documentation.
### Allowing and blocking
Don't use "whitelist" or "blacklist" when referring to allowing or blocking content or traffic.
* When used as a noun, use "allowlist" or "blocklist".
* When used as a verb, use "allow" or "block"
Example: _To **allow** outgoing traffic, add the IP to the **allowlist**._
### Leader and follower
Don't use "master" or "slave" to describe relationships between nodes or processes.
* Use "leader", "main" or "primary," instead of "master."
* Use "follower" or "secondary," instead of "slave."
### Exceptions
When referring to a configuration or settings used by third-party libraries och technologies outside the Grafana project, prefer the original name to avoid confusion.
For example, use "master" when referring to the default Git branch.
The following sections provide general guidelines on topics specific to Grafana documentation. Note that for the most part, these are *guidelines*, not rigid rules. If you have questions, ask in the #docs channel of Grafana Slack.
- Files that are displayed in the help system should have names that are all lowercase, no spaces. Use hyphens instead of spaces. Example: glossary.md
- Documentation file names should match the title. **Note:** This only applies to new files at this time. Do not change the names of older files unless directed to do so.
- Internal reference file names should be all uppercase except the file extension. Example: CONTRIBUTING.md
### Headings
* Write headings in sentence case, not title case.
- This is sentence case
- This Is Title Case
* Task topic headings start with a verb.
- Write a query. Create a dashboard.
* Concept and reference topic headings should be nouns or gerunds. Examples: Contributing to docs, Visualizations, Style guide
Refer to the [Documentation style guide](documentation-style-guide.md) for information about word usage and capitalization guidelines.
### Command line examples
* Do not assume everyone is using Linux. Make sure instructions include enough information for Windows and Mac users to successfully complete procedures.
* Do not add `$` before commands. Make it easy for users to copy and paste commands.
* **Wrong:** `$ sudo yum install grafana`
* **Right:** `sudo yum install grafana`
* Include `sudo` before commands that require `sudo` to work.
For terminal examples and Grafana configuration, use a `bash` code block:
```bash
sudo yum install grafana
```
For HTTP request/response, use an `http` code block:
"Introduction" is the preferred word. Use "intro" if there are space constraints (like on the side menu) or you are specifically trying for a less formal, more conversational tone.
Do not hyphenate when used as an adjective unless the lack of hyphen would cause confusion. For example: _Open source software design is the most open open-source system I can imagine._
