|  | 
|  | 1 | +# Contributing | 
|  | 2 | + | 
|  | 3 | +Contributions are **welcome** and will be fully **credited**. | 
|  | 4 | + | 
|  | 5 | +Please read and understand the contribution guide before creating an issue or pull request. | 
|  | 6 | + | 
|  | 7 | +## Etiquette | 
|  | 8 | + | 
|  | 9 | +This project is open source, and as such, the maintainers give their free time to build and maintain the source code | 
|  | 10 | +held within. They make the code freely available in the hope that it will be of use to other developers. It would be | 
|  | 11 | +extremely unfair for them to suffer abuse or anger for their hard work. | 
|  | 12 | + | 
|  | 13 | +Please be considerate towards maintainers when raising issues or presenting pull requests. Let's show the | 
|  | 14 | +world that developers are civilized and selfless people. | 
|  | 15 | + | 
|  | 16 | +It's the duty of the maintainer to ensure that all submissions to the project are of sufficient | 
|  | 17 | +quality to benefit the project. Many developers have different skillsets, strengths, and weaknesses. Respect the maintainer's decision, and do not be upset or abusive if your submission is not used. | 
|  | 18 | + | 
|  | 19 | +## Viability | 
|  | 20 | + | 
|  | 21 | +When requesting or submitting new features, first consider whether it might be useful to others. Open | 
|  | 22 | +source projects are used by many developers, who may have entirely different needs to your own. Think about | 
|  | 23 | +whether or not your feature is likely to be used by other users of the project. | 
|  | 24 | + | 
|  | 25 | +## Procedure | 
|  | 26 | + | 
|  | 27 | +Before filing an issue: | 
|  | 28 | + | 
|  | 29 | +- Attempt to replicate the problem, to ensure that it wasn't a coincidental incident. | 
|  | 30 | +- Check to make sure your feature suggestion isn't already present within the project. | 
|  | 31 | +- Check the pull requests tab to ensure that the bug doesn't have a fix in progress. | 
|  | 32 | +- Check the pull requests tab to ensure that the feature isn't already in progress. | 
|  | 33 | + | 
|  | 34 | +Before submitting a pull request: | 
|  | 35 | + | 
|  | 36 | +- Check the codebase to ensure that your feature doesn't already exist. | 
|  | 37 | +- Check the pull requests to ensure that another person hasn't already submitted the feature or fix. | 
|  | 38 | + | 
|  | 39 | +- Use the ES2015 syntax. | 
|  | 40 | +- Your patch won't be accepted if it doesn't pass the tests and lints (`npm run test`). | 
|  | 41 | +- If there's a `/demo` section, try to add an example. | 
|  | 42 | +- **Document any change in behaviour:** Make sure the `README.md`, `CHANGELOG.md` and any other relevant documentation are kept up-to-date. | 
|  | 43 | +- **Consider our release cycle:** We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option. | 
|  | 44 | +- **Create feature branches:** Don't ask us to pull from your master branch. | 
|  | 45 | +- **One pull request per feature:** If you want to do more than one thing, send multiple pull requests. | 
|  | 46 | +- **Send coherent history:** Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting. | 
|  | 47 | + | 
|  | 48 | +**Happy coding**! | 
0 commit comments