# Contributing When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change. Please note we have a code of conduct, please follow it in all your interactions with the project. ## Pull Request Process Good pull requests, whether patches, improvements, or new features, are a fantastic help. They should remain focused in scope and avoid containing unrelated commits. **Please ask first** before embarking on any significant pull requests (e.g. implementing features, refactoring code), otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project. 1. [Setup the workspace](#setup-the-workspace) 2. If you cloned before, get the latest changes: ```bash $ git checkout master $ git pull upstream master $ rm -rf node_modules $ npm install ``` 3. Create a new topic branch to contain your changes ```bash $ git checkout -b ``` 4. Make your changes, following the [Coding rules][#coding-rules] 5. Push your topic branch up to your fork: ```bash $ git push origin ``` 6. [Open a Pull Request](https://help.github.com/articles/creating-a-pull-request/#creating-the-pull-request) with a clear title and description. ## Coding rules ### Source code To ensure consistency and quality throughout the source code, all code modifications must have: - No [linting](#lint) errors - A [test](#tests) for every possible case introduced by your code change - **100%** test coverage - [Valid commit message(s)](#commit-message-guidelines) - Documentation for new features - Updated documentation for modified features ### Documentation To ensure consistency and quality, all documentation modifications must: - Prefer [tables](https://help.github.com/articles/organizing-information-with-tables) over [lists](https://help.github.com/articles/basic-writing-and-formatting-syntax/#lists) when listing key values, i.e. List of options with their description - Use [links](https://help.github.com/articles/basic-writing-and-formatting-syntax/#links) when you are referring to: - a concept described somewhere else in the documentation, i.e. How to [contribute](CONTRIBUTING.md) - a third-party product/brand/service, i.e. Integrate with [GitHub](https://github.com) - an external concept or feature, i.e. Create a [GitHub release](https://help.github.com/articles/creating-releases) - a package or module, i.e. [`@nodejs/node`](https://github.com/nodejs/node) - Use the the [single backtick `code` quoting](https://help.github.com/articles/basic-writing-and-formatting-syntax/#quoting-code) for: - commands inside sentences, i.e. the `npm` command - programming language keywords, i.e. `function`, `async`, `String` - packages or modules, i.e. [`@nodejs/node`](https://github.com/nodejs/node) - Use the the [triple backtick `code` formatting](https://help.github.com/articles/creating-and-highlighting-code-blocks) for: - code examples - configuration examples - sequence of command lines ### Commit message guidelines #### Atomic commits If possible, make [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit), which means: - a commit should contain exactly one self-contained functional change - a functional change should be contained in exactly one commit - a commit should not create an inconsistent state (such as test errors, linting errors, partial fix, feature with documentation etc...) A complex feature can be broken down into multiple commits as long as each one maintains a consistent state and consists of a self-contained change. #### Commit message format Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**: ```commit ():