Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: explain PR conventions a bit more #20332

Merged
merged 2 commits into from
May 13, 2022
Merged

docs: explain PR conventions a bit more #20332

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fbac125
docs: explain PR conventions a bit more
rix0rrr May 13, 2022
f42cb4e
Merge branch 'master' into rix0rrr-patch-2
mergify[bot] May 13, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -326,12 +326,17 @@ $ yarn watch & # runs in the background
[conventionalcommits](https://www.conventionalcommits.org).
* The title must begin with `feat(module): title`, `fix(module): title`, `refactor(module): title` or
`chore(module): title`.
* Titles for `feat` and `fix` PRs end up in the change log. Think about what makes most sense for users reading the changelog while writing them.
* `feat`: describe the feature (not the action of creating the commit or PR, for example, avoid words like "added" or "changed")
* `fix`: describe the bug (not the solution)
* Title should be lowercase.
* No period at the end of the title.

* Pull request message should describe _motivation_. Think about your code reviewers and what information they need in
* Pull request body should describe _motivation_. Think about your code reviewers and what information they need in
order to understand what you did. If it's a big commit (hopefully not), try to provide some good entry points so
it will be easier to follow.
* For bugs, describe bug, root cause, solution, potential alternatives considered but discarded.
* For features, describe use case, most salient design aspects (especially if new), potential alternatives.

* Pull request message should indicate which issues are fixed: `fixes #<issue>` or `closes #<issue>`.

Expand Down