-
Notifications
You must be signed in to change notification settings - Fork 27
Contribute
Brenton Gunning edited this page Jun 15, 2014
·
2 revisions
- Always make your contributions for the latest
devbranch, notmaster. - Create separate branches per patch or feature.
- Once done with a patch / feature do not add more commits to a feature branch (pull requests are not repository state snapshots, any change you do in that branch will be included in the pull request).
- If you add a new major feature it's good to add also a sample and test cases (both for showing how it's used and for testing it still works after eventual refactorings).
- If you add a new minor feature it's good to add a test case.
- If you add some assets for the examples (like textures, models, sounds, etc), make sure they have a proper license allowing for their use here (less restrictive the better).
- If you modify existing code (refactoring / optimization / bug fix), run relevant samples and all unit tests to check they didn't break or that there wasn't some performance regress.
- Watch out for Closure compiler warnings when building the libs, there should not be any.
- If some GitHub issue is relevant to patch / feature, it's good to mention issue number with hash (e.g.
#2774) in a commit message to get cross-reference in GitHub web interface. - Format whitespace consistently with the rest of code base.