|
| 1 | +# Contributing Guidelines |
| 2 | + |
| 3 | +Welcome, and thanks in advance for your help! |
| 4 | + |
| 5 | +## When you want to propose a new feature or bug fix |
| 6 | +* Please make sure there is an open issue discussing your |
| 7 | +contribution. |
| 8 | +* If there isn't, please open an issue so we can talk about it before you invest |
| 9 | +time into the implementation. |
| 10 | +* When creating an issue follow the guide that Github shows so we have enough |
| 11 | +information about your proposal. |
| 12 | + |
| 13 | +## Pull Requests |
| 14 | +Please follow these Pull Request guidelines when creating pull requests: |
| 15 | +* If an issue exists, leave a comment there that you are working on a solution |
| 16 | +so nobody else jumps on it. |
| 17 | +* If an issue does not exist, create a new Issue, detail your changes. We |
| 18 | +recommend waiting until we accept it, so you don't waste your precious time. |
| 19 | +* Follow our **Testing** and **Code Style** guidelines below. |
| 20 | +* Start commit messages with a uppercase verb such as "Add", "Fix", "Refactor", |
| 21 | +"Remove". |
| 22 | + |
| 23 | +## Issues |
| 24 | +Please follow these issue guidelines for opening issues: |
| 25 | +* Make sure your issue is not a duplicate. |
| 26 | +* Make sure your issue is for a *feature*, *bug*, or *discussion*, use the |
| 27 | +labels provided in Github where applicable. |
| 28 | + |
| 29 | +## Code Style |
| 30 | +We aim for clean, consistent code style. We're using ESlint to check for |
| 31 | +codestyle issues. If ESlint issues are found our build will fail and we can't |
| 32 | +merge the PR. |
| 33 | + |
| 34 | +Please follow these Code Style guidelines when writing your unit tests: |
| 35 | +* In the root of our repo, use this command to check for styling issues: `npm |
| 36 | +run lint` |
| 37 | + |
| 38 | +## Testing |
| 39 | +We strive for 100% test coverage, so make sure your tests cover as much of your |
| 40 | +code as possible. |
0 commit comments