Add constributing guidelines.

CONTRIBUTING.md

@@ -0,0 +1,85 @@
+# Contributing to Protocol Buffers
+
+We welcome your contributions to protocol buffers. This doc describes the
+process to contribute patches to protobuf and the general guidelines we
+expect contributors to follow.
+
+## Before You Start
+
+We accept patches in the form of github pull requests. If you are new to
+github, please read [How to create github pull requests](https://help.github.com/articles/about-pull-requests/)
+first.
+
+### Contributor License Agreements
+
+Contributions to this project must be accompanied by a Contributor License
+Agreement. You (or your employer) retain the copyright to your contribution,
+this simply gives us 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](https://cla.developers.google.com/about/google-individual?csw=1).
+* If you work for a company that wants to allow you to contribute your work,
+  then you'll need to sign a [corporate CLA](https://cla.developers.google.com/about/google-corporate?csw=1).
+
+### Coding Style
+
+This project follows [Google’s Coding Style Guides](https://github.com/google/styleguide).
+Before sending out your pull request, please familiarize yourself with the
+corresponding style guides and make sure the proposed code change is style
+conforming.
+
+## Contributing Process
+
+Most pull requests should go to the master branch and the change will be
+included in the next major/minor version release (e.g., 3.6.0 release). If you
+need to include a bug fix in a patch release (e.g., 3.5.2), make sure it’s
+already merged to master, and then create a pull request cherry-picking the
+commits from master branch to the release branch (e.g., branch 3.5.x).
+
+For each pull request, a protobuf team member will be assigned to review the
+pull request. For minor cleanups, the pull request may be merged right away
+after an initial review. For larger changes, you will likely receive multiple
+rounds of comments and it may take some time to complete. We will try to keep
+our response time within 7-days but if you don’t get any response in a few
+days, feel free to comment on the threads to get our attention. We also expect
+you to respond to our comments within a reasonable amount of time. If we don’t
+hear from you for 2 weeks or longer, we may close the pull request. You can
+still send the pull request again once you have time to work on it.
+
+Once a pull request is merged, we will take care of the rest and get it into
+the final release.
+
+## Pull Request Guidelines
+
+* If you are a Googler, it is preferable to first create an internal CL and
+  have it reviewed and submitted. The code propagation process will deliver the
+  change to GitHub.
+* Create small PRs that are narrowly focused on addressing a single concern.
+  We often receive PRs that are trying to fix several things at a time, but if
+  only one fix is considered acceptable, nothing gets merged and both author's
+  & review's time is wasted. Create more PRs to address different concerns and
+  everyone will be happy.
+* For speculative changes, consider opening an issue and discussing it first.
+  If you are suggesting a behavioral or API change, make sure you get explicit
+  support from a protobuf team member before sending us the pull request.
+* Provide a good PR description as a record of what change is being made and
+  why it was made. Link to a GitHub issue if it exists.
+* Don't fix code style and formatting unless you are already changing that
+  line to address an issue. PRs with irrelevant changes won't be merged. If
+  you do want to fix formatting or style, do that in a separate PR.
+* Unless your PR is trivial, you should expect there will be reviewer comments
+  that you'll need to address before merging. We expect you to be reasonably
+  responsive to those comments, otherwise the PR will be closed after 2-3 weeks
+  of inactivity.
+* Maintain clean commit history and use meaningful commit messages. PRs with
+  messy commit history are difficult to review and won't be merged. Use rebase
+  -i upstream/master to curate your commit history and/or to bring in latest
+  changes from master (but avoid rebasing in the middle of a code review).
+* Keep your PR up to date with upstream/master (if there are merge conflicts,
+  we can't really merge your change).
+* All tests need to be passing before your change can be merged. We recommend
+  you run tests locally before creating your PR to catch breakages early on.
+  Ultimately, the green signal will be provided by our testing infrastructure.
+  The reviewer will help you if there are test failures that seem not related
+  to the change you are making.