Contributing

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):

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

Use your real name (sorry, no pseudonyms or anonymous contributions.)

If you set your user.name and user.email git configs, you can sign your commit automatically with git commit -s.

Submitting a pull request

  1. Fork the repository. Create a fork of the docker/go-metrics repository on GitHub.
  2. Create a new branch. Create a new branch from the master branch of your fork.
  3. Make your changes. Make your changes to the codebase.
  4. Test your changes. Ensure that your changes pass all tests and follow the project’s coding style.
  5. Commit your changes. Commit your changes with a clear and concise message.
  6. Push your branch to your fork. Push your branch to your fork on GitHub.
  7. Open a pull request. Open a pull request from your branch to the master branch of the original repository.

Contributing code

  • Follow the project’s coding style. The project uses the Go code style.
  • Write unit tests. All new code should be accompanied by unit tests.
  • Document your code. Use Go doc comments to document your code.
  • Keep your changes small and focused. Aim for a single commit for each feature or bug fix.
  • Avoid breaking changes. If your changes could break existing code, clearly document the breaking change and the necessary migration steps.
  • Consider code review. Ask for code review from other developers before merging your changes into the main branch.

Running tests

To run the tests, use the following command:

go test ./...

Documentation

The project uses Go doc comments for documentation. To generate documentation, use the following command:

go doc .

Building the project

To build the project, use the following command:

go build

Running the project

To run the project, use the following command:

go run .

Debugging

If you encounter problems, you can use the following tools to help you debug:

  • go test -v: Run tests with verbose output.
  • go run -debug: Run the project in debug mode.
  • go tool pprof: Generate profiling data.

Code review

  • Open a pull request. Once you have made your changes, open a pull request on GitHub.
  • Request a review. Ask other developers to review your code.
  • Respond to feedback. Respond to any feedback from reviewers.
  • Make changes. Make any necessary changes based on the feedback you received.
  • Merge your pull request. Once your changes have been reviewed and approved, merge your pull request.

Other resources

Maintainers

This project is maintained by a team of developers. You can find a list of maintainers in the MAINTAINERS file.

Code of conduct

This project follows the Docker Code of Conduct.