clusterlint/CONTRIBUTING.md

71 lines
3.0 KiB
Markdown

# Contributing to clusterlint
We welcome all contributions to this project, whether in the form of pull
requests or issues. Please know that all contributions are appreciated, and we
will do our best to review code, answer questions, and resolve issues as time
allows.
That said, in order to maximize the effectiveness of your contributions, please
keep the following guidelines in mind.
## Pull Requests
Pull requests are always welcome. Please:
1. Add thorough, passing unit tests for your changes if applicable.
2. Ensure your changes pass `go vet`, `golint`, and `go test`. These checks
will be run as part of CI.
3. As much as possible, keep git commits and pull requests small. Small commits
and small PRs are easier to review.
4. Write [informative, well-formatted](https://chris.beams.io/posts/git-commit/)
git commit messages.
5. Provide details of your change and why you are making it in the PR
description, referencing issues or other PRs as appropriate.
Remember that any feedback on a PR is intended to improve your contribution or
help the reviewer better understand it, and respond accordingly by either making
changes or replying with questions or clarifications.
### Dependency Management
clusterlint uses Go modules to manage dependencies, but vendors all dependencies
to help ensure reproducible builds and reduce external dependencies in the build
process.
If you need to add or update a dependency, please do the following:
1. Introduce changes that use the new dependency.
2. Add or update the dependency via `go get -m $module`.
3. Clean up `go.mod` with `go mod tidy`.
4. Vendor code with `go mod vendor`.
5. Add the changes to `go.mod`, `go.sum`, and the `vendor` directory in one
commit.
6. Add all other changes (i.e., code that uses the new dependency) in a separate
commit. This will make it easier to review the vendoring change separately
from the code changes.
7. Submit a pull request containing both the vendoring change and the code
changes that depend on it. It's important to keep these in a single PR so
that another developer running `go mod tidy` won't undo your changes.
## Issues
We welcome both bug reports and feature requests as issues. The following
guidelines apply to both, though some parts are more relevant to one or the
other. The maintainers will tag issues as enhancements or bugs upon review.
Before filing an issue, please search to see whether your issue has already been
reported. If it has, consider adding a "thumbs-up" reaction to the issue (NOT a
reply, please!) to indicate to the maintainers that others are seeing the same
problem. Feel free to leave a comment if you can provide additional details not
already given in the issue.
Assuming you have a new issue to report, please:
1. Check that your issue is not already resolved in `master`.
2. Provide as many details as you can on:
1. What you're trying.
2. The expected result.
3. The observed result.
3. Include any relevant environmental information (e.g., Kubernetes version
you're running against).