Codebase list guava-libraries / run/00ccaee0-685a-4d25-b862-909dbae4db94/main CONTRIBUTING.md
run/00ccaee0-685a-4d25-b862-909dbae4db94/main

Tree @run/00ccaee0-685a-4d25-b862-909dbae4db94/main (Download .tar.gz)

CONTRIBUTING.md @run/00ccaee0-685a-4d25-b862-909dbae4db94/mainraw · history · blame

How to contribute
=================

Thank you so much for wanting to contribute to Guava! Here are a few important
things you should know about contributing:

  1. API changes require discussion, use cases, etc. Code comes later.
  2. Pull requests are great for small fixes for bugs, documentation, etc.
  3. Pull requests are not merged directly into the master branch.
  3. Code contributions require signing a Google CLA.

API changes
-----------

We make changes to Guava's public [APIs][], including adding new APIs, very
carefully. Because of this, if you're interested in seeing a new feature in
Guava, the best approach is to create an [issue][] (or comment on an existing
issue if there is one) requesting the feature and describing specific use cases
for it.

If the feature has merit, it will go through a thorough process of API design
and review. Any code should come after this.

[APIs]: http://en.wikipedia.org/wiki/Application_programming_interface
[issue]: https://github.com/google/guava/issues

Pull requests
-------------

Unless the change is a trivial fix such as for a typo, it's generally best to
start by opening a new issue describing the bug or feature you're intending to
fix. Even if you think it's relatively minor, it's helpful to know what people
are working on. And as mentioned above, API changes should be discussed
thoroughly before moving to code.

Some examples of types of pull requests that are immediately helpful:

  - Fixing a bug without changing a public API.
  - Fixing or improving documentation.
  - Improvements to Maven configuration.

Guidelines for any code contributions:

  1. Any significant changes should be accompanied by tests. The project already
     has good test coverage, so look at some existing tests if you're unsure
     how to go about it.
  2. All contributions must be licensed Apache 2.0 and all files must have a
     copy of the boilerplate license comment (can be copied from an existing
     file).
  3. Files should be formatted according to Google's [Java style guide][].
  4. Please squash all commits for a change into a single commit (this can be
     done using `git rebase -i`). Do your best to have a
     [well-formed commit message][] for the change.

[Java style guide]: https://google.github.io/styleguide/javaguide.html
[well-formed commit message]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

#### Merging pull requests ####

Due to Guava's nature as a subset of Google's internal codebase which is
automatically synced to the public GitHub repository, we are unable to merge
pull requests directly into the master branch. Instead, once a pull request is
ready for merging, we'll make the appropriate changes in the internal codebase
and, when the change is synced out, give the pull request author credit for the
commit.

Contributor License Agreement
-----------------------------

Contributions to any Google project must be accompanied by a Contributor
License Agreement. This is not a copyright _assignment_; it simply gives
Google permission to use and redistribute your contributions as part of the
project.

  - 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][]. Please include your GitHub username.
  - If you work for a company that wants to allow you to contribute your work,
    then you'll need to sign a [corporate CLA][].

You generally only need to submit a CLA once, so if you've already submitted
one (even if it was for a different project), you probably don't need to do it
again.

[individual CLA]: https://cla.developers.google.com/about/google-individual
[corporate CLA]: https://developers.google.com/open-source/cla/corporate