Contribute to the Moby Project

Want to contribute to the Moby Project? Here’s a guide to help you get started.

Setting Up Your Development Environment

Before you start contributing, make sure you have a development environment set up. The Moby Project provides a devcontainer.json file that you can use to set up your local or hosted development environment using Visual Studio Code’s Remote Development extension.

Visual Studio Code Remote Development

Reporting Issues

If you encounter a bug or have a suggestion for improvement, please check the issue database to see if it has already been reported. If it has, you can subscribe to the issue to receive updates. If not, please create a new issue with a clear and detailed description, including the output of docker version and docker info.

Quick Contribution Tips and Guidelines

Pull Requests

Pull requests are always welcome. If you’re not sure if your change is worth a pull request, do it anyway! Any significant improvement should be documented as a GitHub issue before anyone starts working on it.

We will do our best to process pull requests quickly. If your pull request is not accepted on the first try, don’t get discouraged! Our contributor’s guide explains the review process we use for simple changes.

Design and Cleanup Proposals

If you have a design or cleanup proposal, please see the advanced contribution section in the contributors guide.

Connect with Other Moby Project Contributors

You can connect with other Moby Project contributors through various channels:

Forums A public forum for users to discuss questions and explore current design patterns and best practices about all the Moby projects. To participate, log in with your Github account or create an account at https://forums.mobyproject.org.
Slack

Register for the Docker Community Slack at https://dockr.ly/slack. We use the #moby-project channel for general discussion, and there are separate channels for other Moby projects such as #containerd.

Twitter You can follow Moby Project Twitter feed to get updates on our products. You can also tweet us questions or just share blogs or stories.

Conventions

When making changes, follow these conventions:

  • Fork the repository and make changes on your fork in a feature branch.
  • Submit tests for your changes.
  • Update the documentation when creating or modifying features.
  • Write clean code.
  • Use clear and descriptive commit messages.

Review

Code review comments may be added to your pull request. Discuss, then make the suggested modifications and push additional commits to your feature branch. Post a comment after pushing.

Merge Approval

Moby maintainers use LGTM (Looks Good To Me) in comments on the code review to indicate acceptance, or use the Github review approval feature.

Sign Your Work

The sign-off is a simple line at the end of the explanation for the patch. Your signature certifies that you wrote the patch or otherwise have the right to pass it on as an open-source patch.

Becoming a Maintainer

The procedures for adding new maintainers are explained in the Moby Technical Steering Committee (TSC) charter.

Community Guidelines

We want to keep the Moby community awesome, growing and collaborative. Please follow our community guidelines:

  • Be nice: Be courteous, respectful and polite to fellow community members.
  • Encourage diversity and participation: Make everyone in our community feel welcome.
  • Keep it legal: Share only content that you own and do not break the law.
  • Stay on topic: Post to the correct channel and avoid off-topic discussions.
  • Don’t send email to the maintainers: Use GitHub mentions instead.

Guideline Violations

We have a 3 strikes method for dealing with guideline violations.

  1. First occurrence: A friendly, but public reminder that the behavior is inappropriate.
  2. Second occurrence: A private message with a warning that any additional violations will result in removal from the community.
  3. Third occurrence: Depending on the violation, we may need to delete or ban your account.

Coding Style

We follow all coding guidelines from the Go community. All new contributions should make a best effort to clean up and make the codebase better than they left it. Remember, the goal is to make the codebase easier for humans to navigate and understand.