github_mirrors/puter
1
0
Fork 0
mirror of https://github.com/HeyPuter/puter.git synced 2025-01-23 06:00:21 +08:00
Code Issues Packages Projects Releases Wiki Activity

doc: update CONTRIBUTING.md

Browse Source
This commit is contained in:
KernelDeimos 2024-08-23 15:09:25 -04:00
parent cdc3947585
commit 6cf7d0ae27
1 changed files with 29 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
CONTRIBUTING.md
View File

@ -57,25 +57,44 @@ See [doc/contributors/index.md](./doc/contributors/index.md) for more informatio
<br>
## PR Standards
We expect the following from pull requests (it makes things easier):
- If you're closing an issue, please reference that issue in the PR description
- Avoid whitespace changes
- No regressions for "appspace" (Puter apps)
<br>
## Commit Messages
Use the imperative, as is the convention in the Linux kernel:
**Note:** we will squash-merge some PRs so they follow . Large PRs should follow conventional commits also. The instructions below are outdated but suitable for most PRs.
- correct: `Improve performance of readdir`
- incorrect: `Improved readdir`
- incorrect: `Improving readdir`
### Conventional Commits
We use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) with the following prefixes:
- `fix:` for bug fixes
- `dev:` instead of `refactor:`; covers more basis
- `tweak:` for small updates
- `sync:` when updating data from another source
- `feat:` for a commit that first introduces a new feature
Commit messages after the prefix should use the imperative (the same convention used in the repo for Linux, which Git was built for):
- correct: `dev: improve performance of readdir`
- incorrect: `dev: improved readdir`
- incorrect: `dev: improving readdir`
We have the following exceptions to this rule:
- If the commit message is in _past tense_, it's a shorthand for the following:
- `Apply changes that would be applied after one had <past tense message>`
- `dev: apply changes that would be applied after one had <past tense message>`
- If the commit message is in _present tense_, it's shorthand for the following:
- `Apply changes that would be applied after <present-tense message>`
- `dev: apply changes that would be applied after <present-tense message>`
For example, the following are correct:
- `Improved readdir`
- interpret this as: `Apply changes that would be applied after one had improved readdir`
- `Improving readdir`
- interpret this as: `Apply changes that would be applied after improving readdir`
- `dev: improved readdir`
- interpret this as: `dev: apply changes that would be applied after one had improved readdir`
- `dev: improving readdir`
- interpret this as: `dev: apply changes that would be applied after improving readdir`
<br>