| 1 | # Contributing to Helix-CLI
|
| 2 |
|
| 3 | This project is an Open Development/Inner Source project and welcomes contributions from everyone who finds it useful or lacking.
|
| 4 |
|
| 5 | ## Code Of Conduct
|
| 6 |
|
| 7 | This project adheres to the Adobe [code of conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to cstaub at adobe dot com.
|
| 8 |
|
| 9 | ## Contributor License Agreement
|
| 10 |
|
| 11 | All third-party contributions to this project must be accompanied by a signed contributor license. This gives Adobe permission to redistribute your contributions as part of the project. [Sign our CLA](http://opensource.adobe.com/cla.html)! You only need to submit an Adobe CLA one time, so if you have submitted one previously, you are good to go!
|
| 12 |
|
| 13 | ## Things to Keep in Mind
|
| 14 |
|
| 15 | This project uses a **commit then review** process, which means that for approved maintainers, changes can be merged immediately, but will be reviewed by others.
|
| 16 |
|
| 17 | For other contributors, a maintainer of the project has to approve the pull request.
|
| 18 |
|
| 19 | # Before You Contribute
|
| 20 |
|
| 21 | * Check that there is an existing issue in GitHub issues
|
| 22 | * Check if there are other pull requests that might overlap or conflict with your intended contribution
|
| 23 |
|
| 24 | # How to Contribute
|
| 25 |
|
| 26 | 1. Fork the repository
|
| 27 | 2. Make some changes on a branch on your fork
|
| 28 | 3. Use `npm run check` to make sure your code can run the tests and adheres to the style guide
|
| 29 | 4. Create a pull request from your branch
|
| 30 |
|
| 31 | In your pull request, outline:
|
| 32 |
|
| 33 | * What the changes intend
|
| 34 | * How they change the existing code
|
| 35 | * If (and what) they breaks
|
| 36 | * Start the pull request with the GitHub issue ID, e.g. #123
|
| 37 |
|
| 38 | Lastly, please follow the [pull request template](https://github.com/adobe/helix-cli/blob/master/.github/pull_request_template.md) when submitting a pull request!
|
| 39 |
|
| 40 | ## Coding Styleguides
|
| 41 |
|
| 42 | We enforce a coding styleguide using `eslint`. As part of your build, run `npm run lint` to check if your code is conforming to the style guide. We do the same for every PR in our CI, so PRs will get rejected if they don't follow the style guide.
|
| 43 |
|
| 44 | You can fix some of the issues automatically by running `npx eslint . --fix`.
|
| 45 |
|
| 46 | ## Commit message format
|
| 47 |
|
| 48 | We use [semantic-release](https://github.com/semantic-release/semantic-release) for release management and require that all commits are properly formatted using the [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines)
|
| 49 |
|
| 50 | In order to help you craft a good commit message, we added [commitizen](https://www.npmjs.com/package/commitizen) as dev dependency, so you can just run
|
| 51 |
|
| 52 | ```
|
| 53 | $ npm run commit
|
| 54 | ```
|
| 55 |
|
| 56 |
|
| 57 | # How Contributions get Reviewed
|
| 58 |
|
| 59 | One of the maintainers will look at the pull request within one week.
|
| 60 | Feedback on the pull request will be given in writing, in GitHub.
|
| 61 |
|
| 62 | # Release Management
|
| 63 |
|
| 64 | Releasing is done using [semantic-release](https://github.com/semantic-release/semantic-release), and every (relevant) commit to the `master` branch gets released automatically. The release will update the version number and add the recent changes to the [CHANGELOG.md](./CHANGELOG.md). It will also create a [release](https://github.com/adobe/helix-cli/releases) in github and finally publish the package to the [Adobe organization on npmjs.org](https://www.npmjs.com/org/adobe).
|