-
-
-
- | Community Slack |
-
- The Docker Community has a dedicated Slack chat to discuss features and issues. You can sign-up with this link.
- |
-
-
- | Forums |
-
- A public forum for users to discuss questions and explore current design patterns and
- best practices about Docker and related projects in the Docker Ecosystem. To participate,
- just log in with your Docker Hub account on https://forums.docker.com.
- |
-
-
- | Twitter |
-
- You can follow Docker's Twitter feed
- to get updates on our products. You can also tweet us questions or just
- share blogs or stories.
- |
-
-
- | Stack Overflow |
-
- Stack Overflow has over 17000 Docker questions listed. We regularly
- monitor Docker questions
- and so do many other knowledgeable Docker users.
- |
-
-
-
-
-### Conventions
-
-Fork the repository and make changes on your fork in a feature branch:
-
-- If it's a bug fix branch, name it XXXX-something where XXXX is the number of
- the issue.
-- If it's a feature branch, create an enhancement issue to announce
- your intentions, and name it XXXX-something where XXXX is the number of the
- issue.
-
-Submit unit tests for your changes. Go has a great test framework built in; use
-it! Take a look at existing tests for inspiration. [Run the full test
-suite](README.md) on your branch before
-submitting a pull request.
-
-Write clean code. Universally formatted code promotes ease of writing, reading,
-and maintenance. Always run `gofmt -s -w file.go` on each changed file before
-committing your changes. Most editors have plug-ins that do this automatically.
-
-Pull request descriptions should be as clear as possible and include a reference
-to all the issues that they address.
-
-Commit messages must start with a capitalized and short summary (max. 50 chars)
-written in the imperative, followed by an optional, more detailed explanatory
-text which is separated from the summary by an empty line.
-
-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. New commits show up in the pull request automatically,
-but the reviewers are notified only when you comment.
-
-Pull requests must be cleanly rebased on top of master without multiple branches
-mixed into the PR.
-
-**Git tip**: If your PR no longer merges cleanly, use `rebase master` in your
-feature branch to update your pull request rather than `merge master`.
-
-Before you make a pull request, squash your commits into logical units of work
-using `git rebase -i` and `git push -f`. A logical unit of work is a consistent
-set of patches that should be reviewed together: for example, upgrading the
-version of a vendored dependency and taking advantage of its now available new
-feature constitute two separate units of work. Implementing a new function and
-calling it in another file constitute a single logical unit of work. The very
-high majority of submissions should have a single commit, so if in doubt: squash
-down to one.
-
-After every commit, make sure the test suite passes. Include documentation
-changes in the same pull request so that a revert would remove all traces of
-the feature or fix.
-
-Include an issue reference like `Closes #XXXX` or `Fixes #XXXX` in the pull
-request description that close an issue. Including references automatically
-closes the issue on a merge.
-
-Please do not add yourself to the `AUTHORS` file, as it is regenerated regularly
-from the Git history.
-
-Please see the [Coding Style](#coding-style) for further guidelines.
-
-### Merge approval
-
-Docker maintainers use LGTM (Looks Good To Me) in comments on the code review to
-indicate acceptance.
-
-A change requires at least 2 LGTMs from the maintainers of each
-component affected.
-
-For more details, see the [MAINTAINERS](MAINTAINERS) page.
-
-### 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. The rules are pretty simple: if you can certify
-the below (from [developercertificate.org](http://developercertificate.org/)):
-
-```
-Developer Certificate of Origin
-Version 1.1
-
-Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
-660 York Street, Suite 102,
-San Francisco, CA 94110 USA
-
-Everyone is permitted to copy and distribute verbatim copies of this
-license document, but changing it is not allowed.
-
-Developer's Certificate of Origin 1.1
-
-By making a contribution to this project, I certify that:
-
-(a) The contribution was created in whole or in part by me and I
- have the right to submit it under the open source license
- indicated in the file; or
-
-(b) The contribution is based upon previous work that, to the best
- of my knowledge, is covered under an appropriate open source
- license and I have the right under that license to submit that
- work with modifications, whether created in whole or in part
- by me, under the same open source license (unless I am
- permitted to submit under a different license), as indicated
- in the file; or
-
-(c) The contribution was provided directly to me by some other
- person who certified (a), (b) or (c) and I have not modified
- it.
-
-(d) I understand and agree that this project and the contribution
- are public and that a record of the contribution (including all
- personal information I submit with it, including my sign-off) is
- maintained indefinitely and may be redistributed consistent with
- this project or the open source license(s) involved.
-```
-
-Then you just add a line to every git commit message:
-
- Signed-off-by: Joe Smith