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 |