| commit | author | age | ||
| 64b419 | 1 | # Contributing |
| SE | 2 | :raised_hands::tada: First off, thanks for taking the time to contribute! :tada::raised_hands: |
| 3 | ||
| c4fc85 | 4 | The following is a set of guidelines for contributing to react-datetime. The purpose of these |
| SE | 5 | guidelines is to maintain a high quality of code *and* traceability. Please respect these |
| 6 | guidelines. | |
| 64b419 | 7 | |
| SE | 8 | ## General |
| c4fc85 | 9 | This repository use tests and a linter as automatic tools to maintain the quality of the code. |
| SE | 10 | These two tasks are run locally on your machine before every commit (as a pre-commit git hook), |
| 11 | if any test fail or the linter gives an error the commit will not be created. They are also run on | |
| 12 | a Travis CI machine when you create a pull request, and the PR will not be merged unless Travis | |
| 13 | says all tests and the linting pass. | |
| 64b419 | 14 | |
| SE | 15 | ## Git Commit Messages |
| 16 | * Use the present tense ("Add feature" not "Added feature") | |
| 17 | * Use the imperative mood ("Move cursor to..." not "Moves cursor to...") | |
| 18 | * Think of it as you are *commanding* what your commit is doing | |
| c4fc85 | 19 | * Git itself uses the imperative whenever it creates a commit on your behalf, so it makes sense |
| SE | 20 | for you to use it too |
| 64b419 | 21 | * Use the body to explain *what* and *why* |
| c4fc85 | 22 | * If the commit is non-trivial, please provide more detailed information in the commit body |
| SE | 23 | message |
| 24 | * *How* you made the change is visible in the code and is therefore rarely necessary to include | |
| 25 | in the commit body message, but *why* you made the change is often harder to guess and is | |
| 26 | therefore useful to include in the commit body message | |
| 64b419 | 27 | |
| c4fc85 | 28 | [Here's a nice blog post on how to write great git messages.](http://chris.beams.io/posts/git-commit/) |
| 64b419 | 29 | |
| SE | 30 | ## Pull Requests |
| 31 | * Follow the current code style | |
| 32 | * Write tests for your changes | |
| c4fc85 | 33 | * Document your changes in the README if it's needed |
| 64b419 | 34 | * End files with a newline |
| c4fc85 | 35 | * There's no need to create a new build for each pull request, we (the maintainers) do this when we |
| SE | 36 | release a new version |
| 37 | ||
| 38 | ## Issues | |
| 39 | * Please be descriptive when you fill in the issue template, this will greatly help us maintainers | |
| 40 | in helping you which will lead to your issue being resolved faster | |
| 41 | * Feature requests are very welcomed, but not every feature that is requested can be guaranteed | |
| 42 | to be implemented | |
