Style guide

This style guide provides some basic guidance for anyone who contributors to best practice content on this site. Providing information with that has overall consistency in structure, style, and terminology helps readers to find and learn more quickly.

Spelling, capitalization, and acronyms

• Use standard American spelling. Use Merriam-Webster’s Collegiate Dictionary as a reference.
• Use sentence case for headings
• Capitalize brand names unless the trademarked or recognized capitalization differs (e.g. npm). Don’t use capital letters to emphasize words.
• Spell out acronyms the first time you use them, particularly if they might not be familiar to some readers. For example spell out “Java Web Token (JWT)” the first time you use it, and then you can use JWT for the rest of the page.

Voice and tone

• Address readers directly with “you” instead of using “we” or “the user”.
• Use active voice when possible instead of passive voice. Active voice makes it easier to identify who is performing an action. For example, “Builds automatically add provenance metadata to the container” is more clear and specific than “Provenance data is added to the container”.
• Use the present tense, including when describing results of performing a step. For example, use “The command verifies dependencies” instead of “The” command will verify dependencies.
• You can use contractions such as “don’t” and “can’t”.

Images

• For architecture diagrams or flowcharts, use SVG files when possible since the image remains sharp when you zoom in.
• Use PNG files for other images.
• For screenshots, don’t include personal or sensitive information, or cover it completely with a solid overlay.

Additional writing guidance

The Google Developer Documentation Style Guide contains detailed guidance for writing clear, concise documentation for a developer audience.