docs: update contributing guidelines and add pr template
This commit is contained in:
parent
af73516c59
commit
6dd833c0ac
|
@ -0,0 +1,15 @@
|
|||
<!-- Please describe the current behavior and link to a relevant issue. -->
|
||||
Fixes <issue-number>
|
||||
|
||||
**If your build fails** due to your commit message not passing the build checks, please review the guidelines here: https://github.com/emqx/emqx/blob/master/CONTRIBUTING.md.
|
||||
|
||||
## PR Checklist
|
||||
Please convert it to a draft if any of the following conditions are not met. Reviewers may skip over until all the items are checked.:
|
||||
|
||||
- [ ] Tests for the changes have been added (for bug fixes / features)
|
||||
- [ ] Docs have been added / updated (for bug fixes / features)
|
||||
- [ ] In case of non-backward compatible changes, reviewer should check this item as a write-off, and add details in **Backward Compatibility** section
|
||||
|
||||
## Backward Compatibility
|
||||
|
||||
## More information
|
|
@ -58,7 +58,7 @@ ignore=title-trailing-punctuation, T1, T2, T3, T4, T5, T6, T8, B1, B2, B3, B4, B
|
|||
# python-style regex that the commit-msg title must match
|
||||
# Note that the regex can contradict with other rules if not used correctly
|
||||
# (e.g. title-must-not-contain-word).
|
||||
regex=^(feat|fix|docs|style|refactor|test|chore|perf)\(.+\): .+
|
||||
regex=^(feat|fix|docs|style|refactor|test|build|ci|revert|chore|perf)(\(.+\))*: .+
|
||||
|
||||
# [body-max-line-length]
|
||||
# line-length=72
|
||||
|
|
|
@ -2,37 +2,80 @@
|
|||
|
||||
You are welcome to submit any bugs, issues and feature requests on this repository.
|
||||
|
||||
## Pull Request Process
|
||||
|
||||
1. Update the README.md with details of changes to the interface.
|
||||
## Commit Message Guidelines
|
||||
|
||||
2. Ensure that each of the commit messages are in the following style:
|
||||
We have very precise rules over how our git commit messages can be formatted. This leads to **more readable messages** that are easy to follow when looking through the **project history**.
|
||||
|
||||
Format: `<type>(<scope>): <subject>`
|
||||
### Commit Message Format
|
||||
|
||||
Type:
|
||||
|
||||
- `feat`: (new feature for the user, not a new feature for build script)
|
||||
- `fix`: (bug fix for the user, not a fix to a build script)
|
||||
- `docs`: (changes to the documentation)
|
||||
- `style`: (formatting, missing semi colons, etc; no production code change)
|
||||
- `refactor`: (refactoring production code, eg. renaming a variable)
|
||||
- `test`: (adding missing tests, refactoring tests; no production code change)
|
||||
- `chore`: (updating grunt tasks etc; no production code change)
|
||||
- `perf`: (performance improvements)
|
||||
|
||||
**Example**
|
||||
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**:
|
||||
|
||||
```
|
||||
feat(build): deterministic compile option
|
||||
^--^ ^---^ ^--------------------------^
|
||||
| | |
|
||||
| | +-> Summary in present tense.
|
||||
| |
|
||||
| |
|
||||
| +-------> Scope of the change.
|
||||
|
|
||||
+-------> Type: chore, docs, feat, fix, perf, refactor, style, or test.
|
||||
<type>(<scope>): <subject>
|
||||
<BLANK LINE>
|
||||
<body>
|
||||
<BLANK LINE>
|
||||
<footer>
|
||||
```
|
||||
|
||||
[Reference](https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716)
|
||||
The **header** with **type** is mandatory. The **scope** of the header is optional. This repository has no predefined scopes. A custom scope can be used for clarity if desired.
|
||||
|
||||
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
|
||||
|
||||
The footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.
|
||||
|
||||
Example 1:
|
||||
|
||||
```
|
||||
feat: add Fuji release compose files
|
||||
fix(script): correct run script to use the right ports
|
||||
|
||||
Previously device services used wrong port numbers. This commit fixes the port numbers to use the latest port numbers .
|
||||
|
||||
Closes: #123
|
||||
```
|
||||
|
||||
### Revert
|
||||
|
||||
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
|
||||
|
||||
### Type
|
||||
|
||||
Must be one of the following:
|
||||
|
||||
- **feat**: New feature for the user, not a new feature for build script
|
||||
- **fix**: Bug fix for the user, not a fix to a build script
|
||||
- **docs**: Documentation only changes
|
||||
- **style**: Formatting, missing semi colons, etc; no production code change
|
||||
- **refactor**: Refactoring production code, eg. renaming a variable
|
||||
- **chore**: Updating grunt tasks etc; no production code change
|
||||
- **perf**: A code change that improves performance
|
||||
- **test**: Adding missing tests, refactoring tests; no production code change
|
||||
- **build**: Changes that affect the CI/CD pipeline or build system or external dependencies (example scopes: travis, jenkins, makefile)
|
||||
- **ci**: Changes provided by DevOps for CI purposes.
|
||||
- **revert**: Reverts a previous commit.
|
||||
|
||||
### Scope
|
||||
|
||||
There are no predefined scopes for this repository. A custom scope can be provided for clarity.
|
||||
|
||||
### Subject
|
||||
|
||||
The subject contains a succinct description of the change:
|
||||
|
||||
- use the imperative, present tense: "change" not "changed" nor "changes"
|
||||
- don't capitalize the first letter
|
||||
- no dot (.) at the end
|
||||
|
||||
### Body
|
||||
|
||||
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
|
||||
|
||||
### Footer
|
||||
|
||||
The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues that this commit **Closes**.
|
||||
|
||||
**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
|
||||
|
||||
<details class="details-reset details-overlay details-overlay-dark" id="jumpto-line-details-dialog" style="box-sizing: border-box; display: block;"><summary data-hotkey="l" aria-label="Jump to line" role="button" style="box-sizing: border-box; display: list-item; cursor: pointer; list-style: none;"></summary></details>
|
Loading…
Reference in New Issue