|
|
@@ -1,24 +1,58 @@
|
|
1
|
|
-Want to contribute? Great! First, read this page (including the small print at the end).
|
|
2
|
|
-
|
|
3
|
|
-### Before you contribute
|
|
4
|
|
-Before we can use your code, you must sign the
|
|
5
|
|
-[Google Individual Contributor License Agreement](https://developers.google.com/open-source/cla/individual?csw=1)
|
|
6
|
|
-(CLA), which you can do online. The CLA is necessary mainly because you own the
|
|
7
|
|
-copyright to your changes, even after your contribution becomes part of our
|
|
8
|
|
-codebase, so we need your permission to use and distribute your code. We also
|
|
9
|
|
-need to be sure of various other things—for instance that you'll tell us if you
|
|
10
|
|
-know that your code infringes on other people's patents. You don't have to sign
|
|
11
|
|
-the CLA until after you've submitted your code for review and a member has
|
|
12
|
|
-approved it, but you must do it before we can put your code into our codebase.
|
|
13
|
|
-Before you start working on a larger contribution, you should get in touch with
|
|
14
|
|
-us first through the issue tracker with your idea so that we can help out and
|
|
15
|
|
-possibly guide you. Coordinating up front makes it much easier to avoid
|
|
16
|
|
-frustration later on.
|
|
17
|
|
-
|
|
18
|
|
-### Code reviews
|
|
19
|
|
-All submissions, including submissions by project members, require review. We
|
|
20
|
|
-use Github pull requests for this purpose.
|
|
21
|
|
-
|
|
22
|
|
-### The small print
|
|
23
|
|
-Contributions made by corporations are covered by a different agreement than
|
|
24
|
|
-the one above, the Software Grant and Corporate Contributor License Agreement.
|
|
|
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. Any significant changes should almost always be accompanied by tests. The
|
|
|
43
|
+ project already has good test coverage, so look at some of the existing
|
|
|
44
|
+ tests if you're unsure how to go about it.
|
|
|
45
|
+
|
|
|
46
|
+ 1. All contributions must be licensed Apache 2.0 and all files must have
|
|
|
47
|
+ a copy of the boilerplate licence comment (can be copied from an existing
|
|
|
48
|
+ file.
|
|
|
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
|