|
| 1 | +# How to contribute # |
| 2 | + |
| 3 | +We'd love to accept your patches and contributions to this project. There are |
| 4 | +a just a few small guidelines you need to follow. |
| 5 | + |
| 6 | + |
| 7 | +## Contributor License Agreement ## |
| 8 | + |
| 9 | +Contributions to any Google project must be accompanied by a Contributor |
| 10 | +License Agreement. This is not a copyright **assignment**, it simply gives |
| 11 | +Google permission to use and redistribute your contributions as part of the |
| 12 | +project. |
| 13 | + |
| 14 | + * If you are an individual writing original source code and you're sure you |
| 15 | + own the intellectual property, then you'll need to sign an [individual |
| 16 | + CLA][]. |
| 17 | + |
| 18 | + * If you work for a company that wants to allow you to contribute your work, |
| 19 | + then you'll need to sign a [corporate CLA][]. |
| 20 | + |
| 21 | +You generally only need to submit a CLA once, so if you've already submitted |
| 22 | +one (even if it was for a different project), you probably don't need to do it |
| 23 | +again. |
| 24 | + |
| 25 | +[individual CLA]: https://developers.google.com/open-source/cla/individual |
| 26 | +[corporate CLA]: https://developers.google.com/open-source/cla/corporate |
| 27 | + |
| 28 | + |
| 29 | +## Submitting a patch ## |
| 30 | + |
| 31 | + 1. It's generally best to start by opening a new issue describing the bug or |
| 32 | + feature you're intending to fix. Even if you think it's relatively minor, |
| 33 | + it's helpful to know what people are working on. Mention in the initial |
| 34 | + issue that you are planning to work on that bug or feature so that it can |
| 35 | + be assigned to you. |
| 36 | + |
| 37 | + 1. Follow the normal process of [forking][] the project, and setup a new |
| 38 | + branch to work in. It's important that each group of changes be done in |
| 39 | + separate branches in order to ensure that a pull request only includes the |
| 40 | + commits related to that bug or feature. |
| 41 | + |
| 42 | + 1. Do your best to have [well-formed commit messages][] with a [good |
| 43 | + description][] for each change. This provides consistency throughout |
| 44 | + the project, and ensures that commit messages are able to be formatted |
| 45 | + properly by various git tools. |
| 46 | + |
| 47 | + 1. Keep PRs [small and focused][] on a single issue. Do not make unrelated |
| 48 | + changes in the same PR "because you're there"; this includes reformatting |
| 49 | + of code, whether automatically or manually. |
| 50 | + |
| 51 | + 1. Finally, push the commits to your fork and submit a [pull request][]. |
| 52 | + |
| 53 | +[forking]: https://help.github.com/articles/fork-a-repo |
| 54 | +[well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html |
| 55 | +[good description]: https://google.github.io/eng-practices/review/developer/cl-descriptions.html |
| 56 | +[pull request]: https://help.github.com/articles/creating-a-pull-request |
| 57 | +[small and focused]: https://google.github.io/eng-practices/review/developer/small-cls.html |
| 58 | + |
| 59 | + |
| 60 | +## Style ## |
| 61 | + |
| 62 | +Contributions should follow the [Go Style Guide](https://google.github.io/styleguide/go). Code should be [formatted] with `gofmt`. |
0 commit comments