# Contributing to Kaniko We'd love to accept your patches and contributions to this project!! To get started developing, see our [DEVELOPMENT.md](./DEVELOPMENT.md). In this file you'll find info on: - [Contributing to Kaniko](#contributing-to-kaniko) - [Contributor License Agreement](#contributor-license-agreement) - [Code reviews](#code-reviews) - [Standards](#standards) - [Commit Messages](#commit-messages) - [Coding standards](#coding-standards) - [Finding something to work on](#finding-something-to-work-on) [code](#coding-standards) - [Finding something to work on](#finding-something-to-work-on) ## Contributor License Agreement Contributions to this project must be accompanied by a Contributor License Agreement. You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project. Head over to to see your current agreements on file or to sign a new one. You generally only need to submit a CLA once, so if you've already submitted one (even if it was for a different project), you probably don't need to do it again. ## Code reviews All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult [GitHub Help](https://help.github.com/articles/about-pull-requests/) for more information on using pull requests. ## Standards This section describes the standards we will try to maintain in this repo. ### Commit Messages All commit messages should follow [these best practices](https://chris.beams.io/posts/git-commit/), specifically: - Start with a subject line - Contain a body that explains _why_ you're making the change you're making - Reference an issue number if one exists, closing it if applicable (with text such as ["Fixes #245" or "Closes #111"](https://help.github.com/articles/closing-issues-using-keywords/)) Aim for [2 paragraphs in the body](https://www.youtube.com/watch?v=PJjmw9TRB7s). Not sure what to put? Include: - What is the problem being solved? - Why is this the best approach? - What other approaches did you consider? - What side effects will this approach have? - What future work remains to be done? ### Coding standards The code in this repo should follow best practices, specifically: - [Go code review comments](https://github.com/golang/go/wiki/CodeReviewComments) ## Finding something to work on Thanks so much for considering contributing to our project!! We hope very much you can find something interesting to work on: - To find issues that we particularly would like contributors to tackle, look for [issues with the "help wanted" label](https://github.com/GoogleContainerTools/kaniko/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22). - Issues that are good for new folks will additionally be marked with ["good first issue"](https://github.com/GoogleContainerTools/kaniko/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22).