| 103 |
- |
1 |
# How to become a contributor and submit your own code
|
|
|
2 |
|
|
|
3 |
## Contributor License Agreements
|
|
|
4 |
|
|
|
5 |
We'd love to accept your sample apps and patches! Before we can take them, we
|
|
|
6 |
have to jump a couple of legal hurdles.
|
|
|
7 |
|
|
|
8 |
Please fill out either the individual or corporate Contributor License Agreement
|
|
|
9 |
(CLA).
|
|
|
10 |
|
|
|
11 |
* If you are an individual writing original source code and you're sure you
|
|
|
12 |
own the intellectual property, then you'll need to sign an [individual CLA]
|
|
|
13 |
(http://code.google.com/legal/individual-cla-v1.0.html).
|
|
|
14 |
* If you work for a company that wants to allow you to contribute your work,
|
|
|
15 |
then you'll need to sign a [corporate CLA]
|
|
|
16 |
(http://code.google.com/legal/corporate-cla-v1.0.html).
|
|
|
17 |
|
|
|
18 |
Follow either of the two links above to access the appropriate CLA and
|
|
|
19 |
instructions for how to sign and return it. Once we receive it, we'll be able to
|
|
|
20 |
accept your pull requests.
|
|
|
21 |
|
|
|
22 |
## Issue reporting
|
|
|
23 |
|
|
|
24 |
* Check that the issue has not already been reported.
|
|
|
25 |
* Check that the issue has not already been fixed in the latest code
|
|
|
26 |
(a.k.a. `master`).
|
|
|
27 |
* Be clear, concise and precise in your description of the problem.
|
|
|
28 |
* Open an issue with a descriptive title and a summary in grammatically correct,
|
|
|
29 |
complete sentences.
|
|
|
30 |
* Include any relevant code to the issue summary.
|
|
|
31 |
|
|
|
32 |
## Pull requests
|
|
|
33 |
|
|
|
34 |
* Read [how to properly contribute to open source projects on Github][2].
|
|
|
35 |
* Fork the project.
|
|
|
36 |
* Use a topic/feature branch to easily amend a pull request later, if necessary.
|
|
|
37 |
* Write [good commit messages][3].
|
|
|
38 |
* Use the same coding conventions as the rest of the project.
|
|
|
39 |
* Commit and push until you are happy with your contribution.
|
|
|
40 |
* Make sure to add tests for it. This is important so I don't break it
|
|
|
41 |
in a future version unintentionally.
|
|
|
42 |
* Add an entry to the [Changelog](CHANGELOG.md) accordingly. See [changelog entry format](#changelog-entry-format).
|
|
|
43 |
* Please try not to mess with the Rakefile, version, or history. If you want to
|
|
|
44 |
have your own version, or is otherwise necessary, that is fine, but please
|
|
|
45 |
isolate to its own commit so I can cherry-pick around it.
|
|
|
46 |
* Make sure the test suite is passing and the code you wrote doesn't produce
|
|
|
47 |
phpunit or phplint offenses.
|
|
|
48 |
* [Squash related commits together][5].
|
|
|
49 |
* Open a [pull request][4] that relates to *only* one subject with a clear title
|
|
|
50 |
and description in grammatically correct, complete sentences.
|
|
|
51 |
|
|
|
52 |
### Changelog entry format
|
|
|
53 |
|
|
|
54 |
Here are a few examples:
|
|
|
55 |
|
|
|
56 |
```
|
|
|
57 |
* ADC Support for User Refresh Tokens (@tbetbetbe[])
|
|
|
58 |
* [#16](https://github.com/google/google-auth-library-php/issues/16): ADC Support for User Refresh Tokens ([@tbetbetbe][])
|
|
|
59 |
```
|
|
|
60 |
|
|
|
61 |
* Mark it up in [Markdown syntax][6].
|
|
|
62 |
* The entry line should start with `* ` (an asterisk and a space).
|
|
|
63 |
* If the change has a related GitHub issue (e.g. a bug fix for a reported issue), put a link to the issue as `[#16](https://github.com/google/google-auth-library-php/issues/16): `.
|
|
|
64 |
* Describe the brief of the change. The sentence should end with a punctuation.
|
|
|
65 |
* At the end of the entry, add an implicit link to your GitHub user page as `([@username][])`.
|
|
|
66 |
* If this is your first contribution to google-auth-library-php project, add a link definition for the implicit link to the bottom of the changelog as `[@username]: https://github.com/username`.
|
|
|
67 |
|
|
|
68 |
[1]: https://github.com/google/google-auth-php-library/issues
|
|
|
69 |
[2]: http://gun.io/blog/how-to-github-fork-branch-and-pull-request
|
|
|
70 |
[3]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
|
|
|
71 |
[4]: https://help.github.com/articles/using-pull-requests
|
|
|
72 |
[5]: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
|
|
|
73 |
[6]: http://daringfireball.net/projects/markdown/syntax
|