Planning: Development
This document is intended to lay out some general principles around development. If you're looking for a development plan, please see Planning: Roadmap.
Primarily, development should follow the GitHub Flow model. This model is based on two GitHub-facilitated actions: forking a repository and using pull requests.
If you'd like to get involved, the easiest way is to find an issue in the issue tracker that you'd like to tackle and comment on it that you'd like to do it, along with any clarification or whatnot that you need to get started. Once you've got something worked up, submit a pull request for review. If you've got an idea that's not reflected in the issue tracker, you can create a new issue and propose it to the group.
Leverage Semantic Versioning 2.0 relatively closely: http://semver.org
Only real variation from the spec is that the PATCH number, under our workflow, may include new features as long as they are part of larger overarching features already in the application (so like a few new fields for a profile, but not the introduction of an events calendar).
| Type | Service | Status |
|---|---|---|
| Continuous Integration | Travis CI |  |
| Test Coverage | Coveralls |  |
| Static Analysis | Code Climate |  |
| Dependencies | Gemnasium |  |