Pull Request and Reviews
All contributions need to be submitted via github pull requests, and they must adhere to the guidelines described below. It is at the discretion of the committer merging the code to determine whether any of the guidelines described below can be violated exceptionally.
All submissions to the master are done through pull requests. If you'd like to make a change:
- Create an issue describing the problem / feature.
- Fork a branch.
- Make your change.
- Verify all tests are passing and checkstyle is happy.
- Submit a pull request.
After review and voting, a pull request should be merged.
- The person performing the merge should different from the person submitting the pull request.
- Changes should be squashed when merging to keep the history concise.
| Status | Description |
|---|---|
| status/1-design-review | Maintainers are expected to comment on the design of the pull request. Review of documentation is expected only in the context of design validation, not for stylistic changes. |
| status/2-code-review | Maintainers are expected to review the code and ensure that it is of good quality and in accordance with the documentation in the PR. |
| status/3-docs-review | Maintainers are expected to review the documentation in its bigger context, ensuring consistency, completeness, validity, and breadth of coverage across all existing and new documentation. |
Note: We would like to thank the communities of Docker and its associated projects for setting up a great set of contribution guidelines and acknowledge that our Issue Triaging guidelines build on theirs