Suggestions for contributing to EpicEditor. For feature and bug fix contributions we try to follow Vincent Driessen's git branching model. No fix or feature is too small. Thanks for contributing.
Before submitting a bug report or feature request, please check to make sure it hasn't already been submitted. You can indicate support for an existing issue by commenting on that issue. When submitting a bug, please include any details necessary to reproduce it (e.g. browser, OS etc). And if you're feeling frisky, including a failing test is super helpful.
If you are fixing a bug you found or adding a feature, please report the bug or feature and take note of the ticket number. After fixing the bug use the following template for your commit messages:
$ git commit -a -m "Ticket #[ticket number] - Fixes foo"
This makes it easier to track stuff down later on.
We rely on Jake to manage tasks, foounit for tests and JSHint for linting. All of these run on NodeJS and can be installed via npm as follows:
$ sudo npm install -g jake foounit jshint
- Fork the project.
- Create a topic branch e.g.
git checkout -b epic-bug-fix
git checkout -b new-feature
. - Add tests where possible.
- Implement your feature or bug fix. Changes should be made to the
src/
files, not the built files inepiceditor/
. - Run tests:
jake lint
andjake test
. - Rebuild: If everything is passing,
jake build
. - Commit and push your changes. Try to reference the associated ticket number in your commit message as noted above.
- Submit your pull request - ideally targeting the
development
branch
A core developer will add a black label with a version number where this was pulled in, i.e. if the fix was included 0.1.1
then we will add a black label with 0.1.1
and close the ticket. Closed tickets do not mean they are in the release!
Yeah. A looser model would be great. Master would stay with releases as it is now, but have a development branch of some sort and
feature/foo-bar
for features.