This document describes how we merge pull requests. See the Contributor's Guide for how to get the code and setup a development environment, and see CONTRIBUTORS.md for the current list of contributors.
We love pull requests. We promptly review them, provide feedback, and merge. We use the Apache 2.0 License. Before we can merge a pull request, we require either:
- A signed Contributor License Agreement (CLA). This can be emailed to cla@agi.com, and only needs to be completed once. The CLA ensures you retain copyright to your contributions, and we have the right to use them and incorporate them into Cesium. There is a CLA for individuals and corporations. Please email completed CLAs and related questions to cla@agi.com.
or
- Every commit is signed-off on to indicate agreement to the Developer Certificate of Origin (DCO). The DCO was originally developed for the Linux kernel, and its text is here: SubmittingPatches. Like the CLA, you retain copyright to your contributions, and we have the right to use them and incorporate them into Cesium. A commit with a sign-off has a line like the following at the bottom:
Signed-off-by: First-name Last-name <email-address>
To sign-off on commits, first make sure your name and email are setup with git:
git config --global --add user.name "First-name Last-name"
git config --global --add user.email "email-address"
Then include the -s
option with every commit, e.g.,
git commit -s -m 'commit message as usual`
To keep our code quality high, please make sure:
- Your code follows the coding conventions.
- Your code passes JSHint. We use the JSHint Eclipse plugin so it runs automatically when we save. You can also run the
jsHint
Ant task from the command line. - To include tests with excellent code coverage for new features. We use Jasmine for writing tests. Run them by browsing to http://localhost:8080/Specs/SpecRunner.html. Verify all new and existing tests pass. For bonus points, test Chrome, Firefox, and other browsers supporting WebGL.
- To update LICENSE.md if third-party libraries were added/updated/removed, including new version of existing libraries. Mention it in CHANGES.md.
If new public classes, functions, or properties were added, also:
- Include reference documentation with code examples. Check out the best practices.
- Update CHANGES.md.
- If the change is significant, add a new Sandcastle example or extend and existing one.