This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Contribution guidelines

How to contribute to continuous delivery best practices.

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.

  1. 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.

  2. Build the docker image:

    docker-compose build

  3. Run the built image:

    docker-compose up

  4. 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:

  1. Stop Docker Compose with Ctrl + C.

  2. Remove the produced images

    docker-compose rm

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:

  1. Fork the Best Practices repo on GitHub.
  2. Make your changes and send a pull request (PR).
  3. 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.)
  4. 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!
  5. Click Details to the right of “Deploy preview ready” to see a preview of your updates.
  6. Continue updating your doc and pushing your changes until you’re happy with the content.
  7. 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:

  1. Click Edit this page in the top right hand corner of the page.
  2. 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.
  3. 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 - 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.