@adobe/helix-pipeline/CONTRIBUTING.md

This project provides helper functions and default implementations for creating Hypermedia Processing Pipelines.

# Contributing to Helix Pipeline

This project is an Open Development/Inner Source project and welcomes contributions from everyone who finds it useful or lacking.

## Code Of Conduct

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.

## Contributor License Agreement

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!

## Things to Keep in Mind

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.

For other contributors, a maintainer of the project has to approve the pull request.

# Before You Contribute

* Check that there is an existing issue in GitHub issues.
* Check if there are other pull requests that might overlap or conflict with your intended contribution.

# How to Contribute

1. Fork the repository.
2. Make some changes on a branch on your fork.
3. Create a pull request from your branch.

In your pull request, outline:

* What the changes intend.
* How they change the existing code.
* If (and what) they breaks.
* Start the pull request with the GitHub issue ID, e.g. #123

Lastly, please follow the [pull request template](PULL_REQUEST_TEMPLATE.md) when submitting a pull request!

Commit messages must respect [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0-beta.3/). You can use `npm run commit` which will guide you to create a commit message that respects the convention. If you know the convention, you can still use your favorite commit mechanism.

## Coding Styleguides

Project Helix uses the [AirBNB JavaScript Style Guide](https://github.com/airbnb/javascript), enforced through `npm lint`.

## Commit Message Format

This project uses a structured commit changelog format that should be used for every commit. Use `npm run commit` instead of your usual `git commit` to generate commit messages using a wizard.

```bash
# either add all changed files
$ git add -A
# or selectively add files
$ git add package.json
# then commit using the wizard
$ npm run commit
```

### Breaking Changes

`npm run commit` will ask you if a change is a breaking change. This is a non-exhaustive list of what we consider breaking changes for `helix-pipeline`

* any change that will remove or rename HTML attributes in the generated HTML output
* any change that will add, remove, or rename HTML tags in the generated HTML output
* any change that will remove or rename configuration settings in `secrets`
* any change that will remove or rename properties exported through `index.js module.exports`
* any change that adds required properties to the schemas
* any change that removes or renames properties in the schemas
# How Contributions get Reviewed

One of the maintainers will look at the pull request within one week. Feedback on the pull request will be given in writing, in GitHub.

# Release Management

The project's committers will release to the [Adobe organization on npmjs.org](https://www.npmjs.com/org/adobe).
Please contact the [Adobe Open Source Advisory Board](https://git.corp.adobe.com/OpenSourceAdvisoryBoard/discuss/issues) to get access to the npmjs organization.

The release process is fully automated using `semantic-release`, increasing the version numbers, etc. based on the contents of the commit messages found.