Community
Learn about how others implement best practices. As you read explore
various implementations, consider the context of the organization in relation
to the needs of your team.
For information about contributing an article to the Community section, see
the contribution guide.
1 - Contribution guidelines
How to contribute to continuous delivery best practices.
Work-in-progress: These guidelines are in development. Netlify is not set up yet.
We use Hugo to format and generate our website, the
Docsy theme for styling and site structure,
and Netlify to manage the deployment of the site.
Hugo is an open-source static site generator that provides us with templates,
content organization in a standard directory structure, and a website generation
engine. You write the pages in Markdown (or HTML if you want), and Hugo wraps
them up into a website.
All submissions, including submissions by project members, require review. We
use GitHub pull requests for this purpose. Consult
GitHub Help for more
information on using pull requests.
Types of contributions
If you’d like to contribute an article to the [Community][/community] section of
this site, the implementations in the article should exemplify the best
practices described in the Learn documentation. Members of the
Best Practices SIG review your PR to determine if the content is a good fit
for adding to the Community section.
You can also create pull requests to suggest improvements to other parts of the
site.
Code of conduct
We expect contributors to read and observe the CD Foundation
Code of Conduct.
Writing style
See the style guide for writing style guidance.
Running the site locally
You can use the included Dockerfile to run the site locally.
-
On Mac and Windows, download and install Docker
Desktop. On Linux, install Docker
engine and Docker
compose.
The installation might require you to reboot your computer for the changes to
take effect.
-
Build the docker image:
-
Run the built image:
-
Open the address http://localhost:1313
in your web browser to load the
docsy-example homepage. You can now make changes to the source files, those
changes will be live-reloaded in your browser.
To clean up your system and delete the container image:
-
Stop Docker Compose with Ctrl + C.
-
Remove the produced images
Quick start with Netlify
Here’s a quick guide to updating the docs. It assumes you’re familiar with the
GitHub workflow and you’re happy to use the automated preview of your doc
updates:
- Fork the Best Practices repo on GitHub.
- Make your changes and send a pull request (PR).
- If you’re not yet ready for a review, add “WIP” to the PR name to indicate
it’s a work in progress. (Don’t add the Hugo property
“draft = true” to the page front matter, because that prevents the
auto-deployment of the content preview described in the next point.)
- Wait for the automated PR workflow to do some checks. When it’s ready,
you should see a comment like this: deploy/netlify — Deploy preview ready!
- Click Details to the right of “Deploy preview ready” to see a preview
of your updates.
- Continue updating your doc and pushing your changes until you’re happy with
the content.
- When you’re ready for a review, add a comment to the PR, and remove any
“WIP” markers.
Updating a single page
If you’ve just spotted something you’d like to change while using the docs, Docsy has a shortcut for you:
- Click Edit this page in the top right hand corner of the page.
- If you don’t already have an up to date fork of the project repo, you are prompted to get one - click Fork this repository and propose changes or Update your Fork to get an up to date version of the project to edit. The appropriate page in your fork is displayed in edit mode.
- Follow the rest of the Quick start with Netlify process above to make, preview, and propose your changes.
Creating an issue
If you’ve found a problem in the best practices content, but you’re not sure how
to fix it yourself, please create an issue in the Best Practices repo.
You can also create an issue about a specific page by clicking the Create Issue
button in the top right hand corner of the page.
Useful resources
1.1 - Style guide
Writing guidelines for contributions to this site.
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.