|
1 | | -# How to contribute to GitHub Slug Action |
| 1 | +# Contribution Guidelines |
2 | 2 |
|
3 | | -## Did you find a bug |
| 3 | +## Issues/pull requests |
| 4 | + |
| 5 | +### When you find a bug |
4 | 6 |
|
5 | 7 | * **Do not open up a GitHub issue if the bug is a security vulnerability**, and instead to refer to our [security policy][1]. |
6 | 8 |
|
7 | 9 | * **Ensure the bug was not already reported** by searching on GitHub under [Issues][2]. |
8 | 10 |
|
9 | 11 | * If you're unable to find an open issue addressing the problem, [open a 'Bug' issue][4]. |
10 | | -Be sure to include a **title and clear description**, as much relevant information as possible, and a **code sample** or an **executable test case** demonstrating the expected behavior that is not occurring. |
| 12 | +Be sure to include a **title and clear description**, as much relevant information as possible, and a **code sample**, or an **executable test case** demonstrating the expected behavior that is not occurring. |
11 | 13 |
|
12 | | -## Did you write a patch that fixes a bug |
| 14 | +### When you write a patch that fixes a bug |
13 | 15 |
|
14 | 16 | * Open a new GitHub pull request with the patch. |
15 | 17 |
|
16 | 18 | * Ensure the PR description clearly describes the problem and solution. |
17 | 19 | Include the relevant issue number if applicable. |
18 | 20 |
|
19 | | -## Do you intend to add a new feature or change an existing one |
| 21 | +### When you intend to add a new feature or change an existing one |
20 | 22 |
|
21 | 23 | * Suggest your change by [opening a 'Feature request' issue][5] and start writing code. |
22 | 24 |
|
23 | | -## Do you have questions about the source code |
| 25 | +### When you want to work on an existing issue |
| 26 | + |
| 27 | +**Note:** Please write a quick comment in the corresponding issue and ask if the feature is still relevant and that you want to jump into the implementation. |
| 28 | + |
| 29 | +Check out our [help wanted](https://github.com/AlexRogalskiy/github-action-json-fields/labels/help%20wanted) or [good first issue](https://github.com/AlexRogalskiy/github-action-json-fields/labels/good%20first%20issue) labels to find issues we want to move forward on with your help. |
| 30 | + |
| 31 | +We will do our best to respond/review/merge your PR according to priority. We hope that you stay engaged with us during this period to insure QA. Please note that the PR will be closed if there hasn't been any activity for a long time (~ 30 days) to keep us focused and keep the repo clean. |
| 32 | + |
| 33 | +### Reviewing Pull Requests |
| 34 | + |
| 35 | +Another really useful way to contribute to project is to review other peoples Pull Requests. Having feedback from multiple people is really helpful and reduces the overall time to make a final decision about the Pull Request. |
| 36 | + |
| 37 | +### Writing / improving documentation |
| 38 | + |
| 39 | +Our documentation lives on GitHub in the [docs](docs) directory. Do you see a typo or other ways to improve it? Feel free to edit it and submit a Pull Request! |
| 40 | + |
| 41 | +### Providing support |
| 42 | + |
| 43 | +The easiest thing you can do to help us move forward and make an impact on our progress is to simply provide support to other people having difficulties with their projects. |
| 44 | + |
| 45 | +You can do that by replying to [issues on Github](https://github.com/AlexRogalskiy/github-action-json-fields/issues). |
| 46 | + |
| 47 | +### When you have questions about the source code |
24 | 48 |
|
25 | 49 | * [open an issue][3] with your question. |
26 | 50 |
|
27 | | -Thanks! |
| 51 | +## Code Style |
| 52 | + |
| 53 | +We aim for clean, consistent code style. We're using ESlint to check for codestyle issues using the eslint/recommended preset. |
| 54 | + |
| 55 | +### Run lint style rules |
| 56 | + |
| 57 | +``` |
| 58 | +npm run lint:all |
| 59 | +``` |
| 60 | + |
| 61 | +### Run format style rules |
| 62 | + |
| 63 | +``` |
| 64 | +npm run format:all |
| 65 | +``` |
| 66 | + |
| 67 | +### Verifying linting style |
| 68 | + |
| 69 | +``` |
| 70 | +npm run check:all |
| 71 | +``` |
| 72 | + |
| 73 | +To help reduce the effort of creating contributions with this style, an [.editorconfig file](http://editorconfig.org/) is provided that your editor may use to override any conflicting global defaults and automate a subset of the style settings. |
| 74 | + |
| 75 | +## Testing |
| 76 | + |
| 77 | +We aim for a (near) 100% test coverage, so make sure your tests cover as much of your code as possible. |
| 78 | + |
| 79 | +### Test coverage |
| 80 | + |
| 81 | +During development, you can easily check coverage by running `npm test`, then opening the `index.html` file inside the `coverage` directory. |
| 82 | + |
| 83 | +Please follow these Testing guidelines when writing your unit tests: |
| 84 | + |
| 85 | +- Include a top-level `describe('ClassName')` block, with the name of the class you are testing |
| 86 | +- Inside that top-level `describe()` block, create another `describe('#methodOne()')` block for each class method you might create or modify |
| 87 | +- For each method, include an `it('should do something')` test case for each logical edge case in your changes |
| 88 | +- As you write tests, check the code coverage and make sure all lines of code are covered. If not, just add more test cases until everything is covered |
| 89 | +- For reference and inspiration, please check our `tests` directory |
| 90 | + |
| 91 | +## Code of Conduct |
| 92 | + |
| 93 | +Finally, to make sure you have a pleasant experience while being in our welcoming community, please read our [code of conduct](CODE_OF_CONDUCT.md). It outlines our core values and believes and will make working together a happier experience. |
| 94 | + |
| 95 | +The :zap: [GitHub Team](https://github.com/AlexRogalskiy) Team |
| 96 | + |
28 | 97 |
|
29 | 98 | [1]: https://github.com/AlexRogalskiy/github-action-json-fields/security/policy |
30 | 99 | [2]: https://github.com/AlexRogalskiy/github-action-json-fields/issues |
|
0 commit comments