If you're thinking about making a contribution to this project, then you're in the right place. First, thank you for taking the time to contribute! Please give everything below a read before attempting to contribute, as it may save you some time and energy when it comes time to submit your awesome new feature, fix, or bug report!
The following contributions are greatly appreciated:
- Code (via pull request)
- New or updated features
- Bug fixes
- Automated tests
- Documentation updates (currently via README)
- Bug reports (via GitHub Issues)
- Feature requests and voting (via GitHub Issues)
GitHub Issues are used for bug and feature tracking. Milestones will be
created for each release version (e.g., v1.0.0
), and any associated Issues or
Pull Requests will be added to the corresponding milestone. Major feature
discussions will happen in separate Hackpads. Issues will still be created for
tracking purposes, but they should typically only contain a link to the
corresponding Hackpad.
Contributing code to an open source project can be fun and rewarding, especially when it's done right. Check out the guidelines below for more information on getting your changes merged into a release.
If you don't have JSCS, install with npm i -g jscs
.
Run jscs .
and jshint .
before committing.
Limit commits to one related set of changes. If you’ve worked on several without
committing, use git add -p
to
break it up into multiple commits.
Try to start and finish one related set of changes in a commit. If your set of
changes spans multiple commits, use interactive rebase [git rebase -i
]
git rebase to squash the commits together.
Always rebase instead of merging commits! Merging makes for an unnecessarily messy commit history, and our goal is to keep the commit history as clean as possible, to make it a useful reference.
Please follow these guidelines for commit messages:
- Separate subject from body with a blank line
- Limit the subject line to 72 characters (shoot for 50 to keep things concise, but use 72 as the hard limit)
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
- Note: Rarely, only the subject line is necessary
For a detailed explanation, please see [How to Write a Git Commit Message] (http://chris.beams.io/posts/git-commit/#seven-rules).
All code contributions can be submitted via GitHub Pull Request. Here are a few guidelines you must adhere to when contributing to this project:
- All pull requests should be made on the
devel
branch, unless intended for a specific release! In that case, they can be made on the branch matching the release version number (e.g.,1.0.0
). If you're not familiar with [forks] fork help and pull requests, please check out those resources for more information. - Begin your feature branches from the latest version of
devel
. - Split up unrelated changes into different PRs, so that they can be discussed independently.
- Before submitting a pull request:
- Rebase to the latest version of
devel
- Add automated tests for any new features
- Ensure all tests are passing by running
./run-tests.sh
from the root directory of the project and viewing the Tinytest output athttp://localhost:3000
- Update README and change log of any modified package with the corresponding changes
- Please follow the existing conventions within each document until detailed conventions can be formalized for each
- Rebase to the latest version of
- Don't bump the version of any package in your PR - we'll take care of that :)
Please file all bug reports, no matter how big or small, as GitHub Issues. Please provide details, and, if possible, include steps to reproduce the bug, a sample GitHub repo with the bug reproduced, or sample code.
This project is still a work in progress. Feature requests are welcome, and can be created and voted on using GitHub Issues!