|
150
|
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 Once your CLA is submitted (or if you already submitted one for
|
|
|
29 another Google project), make a commit adding yourself to the
|
|
|
30 [AUTHORS][] and [CONTRIBUTORS][] files. This commit can be part
|
|
|
31 of your first [pull request][].
|
|
|
32
|
|
|
33 [AUTHORS]: AUTHORS
|
|
|
34 [CONTRIBUTORS]: CONTRIBUTORS
|
|
|
35
|
|
|
36
|
|
|
37 ## Submitting a patch ##
|
|
|
38
|
|
|
39 1. It's generally best to start by opening a new issue describing the bug or
|
|
|
40 feature you're intending to fix. Even if you think it's relatively minor,
|
|
|
41 it's helpful to know what people are working on. Mention in the initial
|
|
|
42 issue that you are planning to work on that bug or feature so that it can
|
|
|
43 be assigned to you.
|
|
|
44
|
|
|
45 1. Follow the normal process of [forking][] the project, and setup a new
|
|
|
46 branch to work in. It's important that each group of changes be done in
|
|
|
47 separate branches in order to ensure that a pull request only includes the
|
|
|
48 commits related to that bug or feature.
|
|
|
49
|
|
|
50 1. Do your best to have [well-formed commit messages][] for each change.
|
|
|
51 This provides consistency throughout the project, and ensures that commit
|
|
|
52 messages are able to be formatted properly by various git tools.
|
|
|
53
|
|
|
54 1. Finally, push the commits to your fork and submit a [pull request][].
|
|
|
55
|
|
|
56 [forking]: https://help.github.com/articles/fork-a-repo
|
|
|
57 [well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
|
|
|
58 [pull request]: https://help.github.com/articles/creating-a-pull-request
|
