This document outlines some of the guidelines that we try and adhere to while working on this project.
👉 Note: before participating in the community, please read our Code of Conduct. By interacting with this repository, organization, or community you agree to abide by our Code of Conduct.
Additionally, if you contribute any source code to this repository, you agree to the terms of the Developer Certificate of Origin. This helps ensure that contributions aren't in violation of 3rd party license terms.
When submitting an issue or bug report, please follow these guidelines:
- Provide as much information as possible (logs, metrics, screenshots, runtime environment, etc).
- Ensure that you are running on the latest stable version (tagged), or
when using
master, provide the specific commit being used. - Provide the minimum needed viable source to replicate the problem.
When submitting a feature request, please follow these guidelines:
- Does this feature benefit others? or just your usecase? If the latter, it will likely be declined, unless it has a more broad benefit to others.
- Please include the pros and cons of the feature.
- If possible, describe how the feature would work, and any diagrams/mock examples of what the feature would look like.
To review what is currently being worked on, or looked into, feel free to head over to the open pull requests or issues list.
- Take a look at the open discussions, and if you feel like you'd like to help out other members of the community, it would be much appreciated!
Below are a few guidelines if you would like to contribute:
- If the feature is large or the bugfix has potential breaking changes, please open an issue first to ensure the changes go down the best path.
- If possible, break the changes into smaller PRs. Pull requests should be focused on a specific feature/fix.
- Pull requests will only be accepted with sufficient documentation describing the new functionality/fixes.
- Keep the code simple where possible. Code that is smaller/more compact does not mean better. Don't do magic behind the scenes.
- Use the same formatting/styling/structure as existing code.
- Follow idioms and community-best-practices of the related language, unless the previous above guidelines override what the community recommends.
- Always test your changes, both the features/fixes being implemented, but also in the standard way that a user would use the project (not just your configuration that fixes your issue).
- Only use 3rd party libraries when necessary. If only a small portion of the library is needed, simply rewrite it within the library to prevent useless imports.
- See golang/go/wiki/CodeReviewComments
- This project uses golangci-lint for
Go-related files. This should be available for any editor that supports
gopls, however you can also run it locally withgolangci-lint runafter installing it.
- Follow container best practices, like keeping images as small as possible.
- This project uses shellcheck
for linting
Dockerfile's. You can also use native docker extensions. This is available in VSCode here.
- This project uses shellcheck
for linting
bashandshscripts. It helps write proper scripts, and should help catch any potential bugs/issues. This is available in VSCode here. shfmtshould be used if possible, to auto-format shell scripts. The flags that should generally be used are:shfmt -s -bn -ci -sr. This is available in VSCode here.
- 🗝️ Find a vulnerability? Check out our Security and Disclosure policy.
- 🔗 Repository License.
- Support
- Code of Conduct.