Edit This Page

Documentation Style Guide

This page gives writing style guidelines for the Kubernetes documentation. These are guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

For additional information on creating new content for the Kubernetes docs, follow the instructions on using page templates and creating a documentation pull request.

• Documentation formatting standards
  • Capitalize API objects
  • Use angle brackets for placeholders
  • Use bold for user interface elements
  • Use italics to define or introduce new terms
  • Use code style for filenames, directories, and paths
• Code snippet formatting
  • Use code style for inline code and commands
  • Don’t include the command prompt
  • Separate commands from output
• Content best practices
  • Use present tense
  • Use active voice
  • Use simple and direct language
  • Address the reader as “you”
• Patterns to avoid
  • Avoid using “we”
  • Avoid jargon and idioms
  • Avoid statements about the future
  • Avoid statements that will soon be out of date
  • What’s next

Documentation formatting standards

Capitalize API objects

Capitalize the names of API objects. Refer to API objects without saying “object.”

Use angle brackets for placeholders

Use angle brackets for placeholders. Tell the reader what a placeholder represents.

1. Display information about a pod:

    kubectl describe pod <pod-name>
   

   where <pod-name> is the name of one of your pods.

Use bold for user interface elements

Use italics to define or introduce new terms

Use code style for filenames, directories, and paths

Code snippet formatting

Use code style for inline code and commands

For inline code in an HTML document, use the <code> tag. In a Markdown document, use the backtick (`).

Don’t include the command prompt

Separate commands from output

Verify that the pod is running on your chosen node:

kubectl get pods --output=wide

The output is similar to this:

NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
nginx    1/1       Running   0          13s    10.200.0.4   worker0

Content best practices

This section contains suggested best practices for clear, concise, and consistent content.

Use present tense

Exception: Use future or past tense if it is required to convey the correct meaning.

Use active voice

Exception: Use passive voice if active voice leads to an awkward construction.

Use simple and direct language

Use simple and direct language. Avoid using unnecessary phrases, such as saying “please.”

Address the reader as “you”

Patterns to avoid

Avoid using “we”

Using “we” in a sentence can be confusing, because the reader might not know whether they’re part of the “we” you’re describing.

Avoid jargon and idioms

Some readers speak English as a second language. Avoid jargon and idioms to help make their understanding easier.

Avoid statements about the future

Avoid making promises or giving hints about the future. If you need to talk about an alpha feature, put the text under a heading that identifies it as alpha information.

Avoid statements that will soon be out of date

Avoid words like “currently” and “new.” A feature that is new today might not be considered new in a few months.

What’s next

• Learn about writing a new topic.
• Learn about using page templates.
• Learn about staging your changes
• Learn about creating a pull request.

Create an Issue Edit this Page