We'd love to have you join our group of contributors! Please e-mail your areas of interest and your availability to contributing@code.org, and we’ll be happy to match you with a project.
This project adheres to the [Open Code of Conduct][code-of-conduct]. By participating, you are expected to honor this code. [code-of-conduct]: http://todogroup.org/opencodeofconduct/#Code.org/abuse@code.org
You can start setting up with these next steps:
-
Anyone who would like to contribute to Code.org projects must read and sign the Contributor License Agreement. We can't accept pull requests from contributors who haven't yet signed the CLA.
-
Get your local development build working by following our SETUP. Fork our repo and make sure to merge our staging branch into yours WEEKLY as we do update frequently.
Please make sure your code conforms to our style guide. We have implemented linting to help you with this:
- To ensure our precommit linting hook is installed, run
rake install:hooks
. You should only have to do this once. - To lint the entire project, run
rake lint
from the repository root. This will check all Ruby, JavaScript and HAML. - To lint only part of the project, run one of these commands from the repository root:
- dashboard:
cd dashboard && rubocop && haml-lint
- pegasus Ruby:
cd pegasus && rubocop
- pegasus HAML:
haml-lint pegasus
- apps: See the apps README
- dashboard:
Please test your changes before submitting them to us!
We support recent versions of Firefox, Chrome, Internet Explorer, Edge, iOS Safari and the Android browsers (full list of supported browsers and versions). Be sure to try your feature out in IE9, iOS and Android if it's a risk. Sauce Labs or BrowserStack live let you run manual tests in these browsers remotely.
For dashboard changes, be sure to test your changes using rake test
. For apps or blockly changes, see our grunt testing instructions.
Our continuous integration server regularly runs a suite of UI tests using Selenium / Cucumber which run against many browsers via Sauce Labs, and can also be run locally using chromedriver
. See the README in that folder for instructions.
If your changes might affect level paths, blockly UI, or critical path site logic, be sure to test your changes with a local UI test.
Once you've linted and tested your changes, send us a pull request! Contributors should follow the GitHub fork-and-pull model to submit pull requests into this repository. Code.org developers should also work on a branch and use a pull request to merge to staging; please do not merge directly to the code-dot-org/staging branch.
- On your fork, you'll either push to your own finished branch or checkout a new branch for your feature before you start your feature
git checkout -b branch_name
- Develop the new feature and push the changes to your fork and branch
git add YYY
git commit -m "ZZZ"
git push origin branch_name
- Go to the code-dot-org GitHub page
- For your submission to be reviewed
- Click on the "Pull Request" link, look over and confirm your diff
- Submit a pull request for your branch to be merged into staging
- For bonus points, include screenshots in the description. Command + Ctrl + Shift + 4 in OS X lets you copy a screen selection to your clipboard, which GitHub will let you paste right into the description
- After your pull request is merged into staging, you can review your changes on the following sites: