Contributing

General Workflow - Based on the Github workflow

Clone the repo
Create a branch from the development branch. - Your branch name should be descriptive (e.g., feature/refactor-authentication, feature/user-content-cache-key, feature/make-retina-avatars), so that others can see what is being worked on. Use the following naming conventions for branching:

Add commits to your feature branch. - Commit messages are important, by writing clear commit messages, you can make it easier for other people to follow along and provide feedback.
Open a Pull Request to the development branch. - Write the PR title in the format of (feat) Implemented sign in authorization [Closes #<issue num>] in order to have the PR's sync with waffle.io
Discuss and review your code. - Once a Pull Request has been opened, the person or team reviewing your changes may have questions or comments. Perhaps the coding style doesn't match project guidelines, the change is missing unit tests, or maybe everything looks great and props are in order. Pull Requests are designed to encourage and capture this type of conversation.
Development Merge - Once your pull request has been reviewed and the branch passes tests, the pull request can be merged into the development branch, to be tested into production.
Master Merge - Now that your changes have been verified in production, it is time to merge your code into the master branch. Once merged, Pull Requests preserve a record of the historical changes to your code. Because they're searchable, they let anyone go back in time to understand why and how a decision was made.
Remove the feature branch - Upon succesfully merge to master make sure to clean the relative branches from the published branches on origin.

Details and pro-tips about the Github workflow and branching strategies in general:

Thanks for contributing!

Uphold the current code standard:
- Keep your code DRY.
- Apply the boy scout rule.
- Follow the Style guide
Run the tests npm test before submitting a pull request.
Tests are very, very important. Submit tests if your pull request contains new, testable behavior.

This is just to help you organize your process

Did you branch out of development? (never branch out from existing feature brances/master)
Did I follow the correct naming convention for my branch?
Is my branch focused on a single main change?
Do all of my changes directly relate to this change?
Did I write a clear pull request message detailing what changes I made?
Did I get a code review?
Did I make any requested changes from that code review?

If you follow all of these guidelines and make good changes, you should have no problem getting your changes merged in.