Quickstart code or doc contribution

If you’d like to improve the code of any of Docker’s projects, we would love to have your contributions. All of our projects’ code repositories are on GitHub.

If you want to contribute to the docker/docker repository you should be familiar with or invested in learning Go or the Markdown language. If you know other languages, investigate our other repositories—not all of them run on Go.

Code contribution workflow

Below is the general workflow for contributing Docker code or documentation. If you are an experienced open source contributor you may be familiar with this workflow. If you are new or just need reminders, the steps below link to more detailed documentation in Docker’s project contributors guide.

1. Get the software you need.

   This explains how to install a couple of tools used in our development environment. What you need (or don’t need) might surprise you.

2. Configure Git and fork the repo.

   Your Git configuration can make it easier for you to contribute. Configuration is especially key if you are new to contributing or to Docker.

3. Learn to work with the Docker development container.

   Docker developers run docker in docker. If you are a geek, this is a pretty cool experience.

4. Claim an issue to work on.

   We created a filter listing all open and unclaimed issues for Docker.

5. Work on the issue.

   If you change or add code or docs to a project, you should test your changes as you work. This page explains how to test in our development environment.

   Also, remember to always sign your commits as you work! To sign your commits, include the -s flag in your commit like this:

    $ git commit -s -m "Add commit with signature example"
   

   If you don’t sign Gordon will get you!

6. Create a pull request.

   If you make a change to fix an issue, add reference to the issue in the pull request. Here is an example of a perfect pull request with a good description, issue reference, and signature in the commit:

   

   We also have checklist that describes what each pull request needs.

7. Participate in the pull request review till a successful merge.

Feedback? Suggestions? Can't find something in the docs?
Edit this page ● Request docs changes ● Get support
Rate this page: