forked from KolibriOS/kolibrios
Compare commits
4 Commits
add-readme
...
improvemen
Author | SHA1 | Date | |
---|---|---|---|
49399adda6 | |||
59685a6ac5 | |||
b72d3f1035 | |||
59bb13d6de |
@@ -11,24 +11,39 @@ Each of these types is described in detail below.
|
|||||||
|
|
||||||
## Issues
|
## Issues
|
||||||
|
|
||||||
You can help us by submitting issues about problems found in the system. Currently, there are two main ways of submitting an issue in the project: **Bug Reports** and **Feature Requests**:
|
You can help us by submitting issues about problems found in the system.
|
||||||
|
Currently, there are two main ways of submitting an issue in the project:
|
||||||
|
**Bug Reports** and **Feature Requests**:
|
||||||
|
|
||||||
- Bug Reports are suitable if you find a **bug** (crash, error, unexpected behavior) in some part of the system (kernel, drivers, apps, etc.) and want to report it
|
- Bug Reports are suitable if you find a **bug** (crash, error, unexpected
|
||||||
- Feature Request are used, when you want to propose some **improvement** to the system (missing features, improved user experience, etc.)
|
behavior) in some part of the system (kernel, drivers, apps, etc.) and want to
|
||||||
|
report it
|
||||||
|
- Feature Request are used, when you want to propose some **improvement** to
|
||||||
|
the system (missing features, improved user experience, etc.)
|
||||||
|
|
||||||
## Pull requests
|
## Pull requests
|
||||||
|
|
||||||
You can also help us by submitting code via pull requests. The process of submitting a pull request consists of the following steps:
|
You can also help us by submitting code via pull requests. The process of
|
||||||
|
submitting a pull request consists of the following steps:
|
||||||
|
|
||||||
1. Find what you want to implement or improve
|
1. Find what you want to implement or improve
|
||||||
2. Make a fork of kolibrios (or other needed) repository
|
2. Make a fork of kolibrios (or other needed) repository
|
||||||
3. Create a branch with a name that matches your changes
|
3. Create a branch with a name that matches [the style](#branch-style)
|
||||||
4. Implement and test the changes
|
4. Implement and test the changes
|
||||||
5. Create commits according to the [accepted style](#commit-style)
|
5. Create commits according to the [accepted style](#commit-style)
|
||||||
6. Create and submit a pull request into `main` branch
|
6. Create and submit a pull request into `main` branch
|
||||||
7. Wait for CI/CD pipelines and code review to pass
|
7. Wait for CI/CD pipelines and code review to pass
|
||||||
|
|
||||||
When a pull request is submitted, at least two project participants must conduct a code review, after which the proposed changes can be corrected (if it's necessary) and merged into the project.
|
When a pull request is submitted, at least two project participants must conduct
|
||||||
|
a code review, after which the proposed changes can be corrected (if it's
|
||||||
|
necessary) and merged into the project.
|
||||||
|
|
||||||
|
## Branch style
|
||||||
|
|
||||||
|
1. Your branch name should be as short as possible, but describes your changes
|
||||||
|
2. Words should be divided by minus sign (`-`)
|
||||||
|
3. Optionally, might starts with general [type](#types) of your future PR
|
||||||
|
with slash (`/`): `refactor/nasm-to-fasm`, `update/demos`, `fix/cp866-charset`
|
||||||
|
|
||||||
## Commit style
|
## Commit style
|
||||||
|
|
||||||
@@ -36,19 +51,61 @@ When a pull request is submitted, at least two project participants must conduct
|
|||||||
|
|
||||||
The commit message should look like this:
|
The commit message should look like this:
|
||||||
|
|
||||||
```test
|
```
|
||||||
Commit message header
|
type(scope): commit message header
|
||||||
|
|
||||||
Commit message body, if needed
|
Commit message body, if needed
|
||||||
```
|
```
|
||||||
|
- Use the present tense ("Add feature" not "Added feature")
|
||||||
|
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
|
||||||
|
- Limit the first line to 72 characters or less
|
||||||
|
- Reference issues and pull requests liberally after the first line
|
||||||
|
- When only changing documentation, include [ci skip] in the commit title
|
||||||
- Commit message header and body should reflect changes made in commit
|
- Commit message header and body should reflect changes made in commit
|
||||||
- Commit message header should start with a capital letter
|
|
||||||
- Commit message body should be separated from the header by one empty line
|
|
||||||
|
|
||||||
### Length
|
### Types
|
||||||
|
|
||||||
Maximum number of characters in a commit header is **72** (standard for **Git**). Also, **72** is the maximum length of a line in a commit body.
|
| Type | Description |
|
||||||
|
| :--------------: | :------------------------------------------------ |
|
||||||
|
| `feat / feature` | for new feature implementing commit |
|
||||||
|
| `update` | for update commit |
|
||||||
|
| `bug` | for bug fix commit |
|
||||||
|
| `security` | for security issue fix commit |
|
||||||
|
| `performance` | for performance issue fix commit |
|
||||||
|
| `improvement` | for backwards-compatible enhancement commit |
|
||||||
|
| `breaking` | for backwards-incompatible enhancement commit |
|
||||||
|
| `deprecated` | for deprecated feature commit |
|
||||||
|
| `i18n` | for i18n (internationalization) commit |
|
||||||
|
| `a11y` | for a11y (accessibility) commit |
|
||||||
|
| `refactor` | for refactoring commit |
|
||||||
|
| `docs` | for documentation commit |
|
||||||
|
| `example` | for example code commit |
|
||||||
|
| `test` | for testing commit |
|
||||||
|
| `deps` | for dependencies upgrading or downgrading commit |
|
||||||
|
| `config` | for configuration commit |
|
||||||
|
| `build` | for packaging or bundling commit |
|
||||||
|
| `release` | for publishing commit |
|
||||||
|
| `wip` | for work in progress commit |
|
||||||
|
| `chore` | for other operations commit |
|
||||||
|
|
||||||
|
### Scopes
|
||||||
|
|
||||||
|
> [!NOTE]
|
||||||
|
> Scopes are optional
|
||||||
|
|
||||||
|
| Scope | Description |
|
||||||
|
| :----: | :------------------------------- |
|
||||||
|
| `krn` | kernel |
|
||||||
|
| `drv` | drivers |
|
||||||
|
| `lib` | libraries |
|
||||||
|
| `app` | userspace applications |
|
||||||
|
| `skin` | skins |
|
||||||
|
| `data` | images, configs, resources, etc. |
|
||||||
|
|
||||||
|
> [!NOTE]
|
||||||
|
> If changes are made to a specific component, the name of the component
|
||||||
|
> separated by `/` character needs to be specified. For example:
|
||||||
|
> `app/shell`, `lib/libimg`
|
||||||
|
|
||||||
## Merge commits
|
## Merge commits
|
||||||
|
|
||||||
@@ -57,4 +114,5 @@ Maximum number of characters in a commit header is **72** (standard for **Git**)
|
|||||||
|
|
||||||
## Conclusion
|
## Conclusion
|
||||||
|
|
||||||
We hope this small instructions will help you to get familiar with KolibriOS contribution rules and inspire you to participate in the work of this project.
|
We hope this small instructions will help you to get familiar with KolibriOS
|
||||||
|
contribution rules and inspire you to participate in the work of this project.
|
||||||
|
Reference in New Issue
Block a user