How to become a contributor and submit your own code

Contributor License Agreements

We'd love to accept your sample apps and patches! Before we can take them, we have to jump a couple of legal hurdles.

Please fill out either the individual or corporate Contributor License Agreement (CLA).

• If you are an individual writing original source code and you're sure you own the intellectual property, then you'll need to sign an individual CLA.
• If you work for a company that wants to allow you to contribute your work, then you'll need to sign a corporate CLA.

Follow either of the two links above to access the appropriate CLA and instructions for how to sign and return it. Once we receive it, we'll be able to accept your pull requests.

Issue reporting

• Check that the issue has not already been reported.
• Check that the issue has not already been fixed in the latest code (a.k.a. the main branch).
• Be clear, concise and precise in your description of the problem.
• Open an issue with a descriptive title and a summary in grammatically correct, complete sentences.
• Include any relevant code to the issue summary.

Pull requests

• Read how to properly contribute to open source projects on Github.
• Fork the project.
• Use a topic/feature branch to easily amend a pull request later, if necessary.
• Write good commit messages.
• Use the same coding conventions as the rest of the project.
• Commit and push until you are happy with your contribution.
• Make sure to add tests for it. This is important so I don't break it in a future version unintentionally.
• Add an entry to the Changelog accordingly. See changelog entry format.
• Please try not to mess with the Rakefile, version, or history. If you want to have your own version, or is otherwise necessary, that is fine, but please isolate to its own commit so I can cherry-pick around it.
• Make sure the test suite is passing and the code you wrote doesn't produce RuboCop offenses.
• Squash related commits together.
• Open a pull request that relates to only one subject with a clear title and description in grammatically correct, complete sentences.

Changelog entry format

Here are a few examples:

* makes the scope parameter's optional in all APIs. (@tbetbetbe[])
* [#14](https://github.com/google/google-auth-library-perl/issues/14): ADC Support for JWT Service Tokens. ([@tbetbetbe][])

• Mark it up in Markdown syntax.
• The entry line should start with * (an asterisk and a space).
• If the change has a related GitHub issue (e.g. a bug fix for a reported issue), put a link to the issue as [#123](https://github.com/google/google-auth-library-perl/issues/11): .
• Describe the brief of the change. The sentence should end with a punctuation.
• At the end of the entry, add an implicit link to your GitHub user page as ([@username][]).
• If this is your first contribution to google-auth-library-perl project, add a link definition for the implicit link to the bottom of the changelog as [@username]: https://github.com/username.