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
- Fork the repository. Create a fork of the
docker/go-metrics
repository on GitHub. - Create a new branch. Create a new branch from the
master
branch of your fork. - Make your changes. Make your changes to the codebase.
- Test your changes. Ensure that your changes pass all tests and follow the project’s coding style.
- Commit your changes. Commit your changes with a clear and concise message.
- Push your branch to your fork. Push your branch to your fork on GitHub.
- 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.