Contributing

#Contributing to EpicEditor

Suggestions for contributing to EpicEditor. No fix or feature is too small. Thanks for contributing!

##Issues

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, include a failing test!

Pull requests

If you are fixing a bug or adding a feature, please report the bug or feature and reference the ticket number in the commit message, for example:

$ git commit -m "Ticket #75 - add semicolon."

This makes it easier to track stuff down later on and will also add the commits directly into the GitHub issue with the matching issue number like comments.

Requirements

We rely on Jake to manage tasks, Mocha and expect.js for tests, JSHint for linting, UglifyJS for minification, and Marked to generate the docs. All of these run on NodeJS and can be installed via npm as follows:

Jake must be installed globally:

$ npm install -g jake

Additional dev dependencies can be installed from the EpicEditor directory via npm as follows:

$ cd EpicEditor
$ npm install

Flow

1. Fork the project.
2. Create a topic branch off develop e.g. $ git checkout -b myfeature develop $ git checkout -b hotfix-1.2.1 master.
3. Turn on jake watch so changes will automatically get built.
4. Add tests where applicable.
5. Implement your feature or bug fix. Changes to EpicEditor core should be made to the src/ files. Not the built files in epiceditor/.
6. Run tests: $ jake test then go to: http://localhost:8888/test/tests.html
7. Rebuild: If everything is passing, $ jake build. This will run linting and if linting fails you'll need to fix your lint errors and run $ jake build again.
8. Commit and push your changes. Try to reference the associated ticket number in your commit message as noted above.
9. Submit your pull request - ideally targeting the develop branch for anything other than hotfixes.

Updating Docs

The flow to update the docs is similar. Do steps 1 and 2 above then:

1. Make your changes to the /docs/* files or README.md. NOTE: index.html is built from the README and should not be directly modified.
2. If you modify the README.md, header.html, or footer.html files you'll need to run $ jake docs to rebuild index.html and see the changes, or you can just run jake watch and the docs will automatically be built when you save the README.md file.
3. Follow steps 7 and 8 above.

Merges

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 branch (master) yet!

Development tips

• You can run $ jake build:force to skip the linter allowing you to put in debug statements or other lint-failing code while you're working.
• We don't use gitflow, but we use develop as our working branch and master is the release branch. Always be in develop when working on something. master can be up to a month old if there hasn't been any hotfixes.