mirror of
https://gitlab.gnome.org/Rirusha/Cassette.git
synced 2025-06-28 12:49:52 +00:00
docs: update CONTRIBUTING.md
This commit is contained in:
Kirill Unitsaev
parent
48028e5b30
commit
ed93ba2613
2 changed files with 61 additions and 61 deletions
61
CONTRIBUTING.md
Normal file
61
CONTRIBUTING.md
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
## How to contribute
|
||||
|
||||
If you don't know what to do, then:
|
||||
* All scheduled tasks are in the issue section and have the "enhancement" label.
|
||||
* All known problems are in the same place and have a "bug" label.
|
||||
|
||||
Choose tasks from the nearest versions. You can find a list of them [here](https://github.com/Rirusha/Cassette/milestones). This will both speed up the release of the next version and facilitate the review, so you will not need to switch from one global problem to another.
|
||||
|
||||
Also, if you decide to fix some bug described in the issue, first make sure that it can still be reproduced in the `main` branch.
|
||||
|
||||
Also, if you think that the application is missing something or you have found a bug, then do not hesitate to create an issue.
|
||||
|
||||
## Naming commits
|
||||
The message header should look like:
|
||||
```
|
||||
feat: add a play button to the `Widget name`
|
||||
|
||||
The button was missing, so it had to be added
|
||||
```
|
||||
This is an example. The rules are described in more detail [here](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional). Also, the message body is optional if the information in the header is exhaustive. Also here is a list of all types of commits with descriptions:
|
||||
|
||||
* `build`: Used for changes related to the system build or external dependencies.
|
||||
|
||||
* `chore`: Usually includes changes that are not directly related to the code or tests, for example, updating documentation, configuring the development environment, upgrading the version, etc.
|
||||
|
||||
* `ci`: Refers to changes related to configuring or improving CI.
|
||||
|
||||
* `docs`: Used for changes related only to documentation, such as correcting typos, updating the README, or adding comments to the code.
|
||||
|
||||
* `feat`: Indicates the addition of new functionality or features to the project.
|
||||
|
||||
* `fix`: Refers to fixing errors in the code or fixing problems in the project.
|
||||
|
||||
* `perf`: Used when changes are made to improve performance.
|
||||
|
||||
* `refactor`: Refers to changes that do not add new functionality, but only change the structure or organization of existing code.
|
||||
|
||||
* `revert`: Used to undo previous commits in the project history.
|
||||
|
||||
* `style`: Refers to changes in the formatting of the code, for example, edits of spaces, indents, line breaks, etc.
|
||||
|
||||
* `test`: Used to add or modify test code, for example, testing new functionality or correcting existing tests.
|
||||
|
||||
* `po`: Used to add or change a translation.
|
||||
|
||||
## Creating Pull Requests
|
||||
All Pull Requests must be made in the `master` branch. If you close an issue, then link to it with the keyword "close" in the commit body, for example:
|
||||
```
|
||||
fix: fix incorrect behavior
|
||||
|
||||
close #123
|
||||
```
|
||||
|
||||
## Formatting the code
|
||||
If you are using Visual Studio Code, then there is a task to run the linter. Otherwise, use the configuration in the root of the repository in the linter: vala-lint.conf, CI uses it exactly.
|
||||
|
||||
## Development
|
||||
Check the build using flatpak, as this is the only officially supported version.
|
||||
|
||||
## Testing
|
||||
Writing or supplementing existing tests for the client is highly welcome.
|
||||
|
|
@ -1,61 +0,0 @@
|
|||
## Как внести вклад
|
||||
|
||||
Если вы не знаете, чем занятся, то:
|
||||
* Все запланированные задачи лежат в разделе issue и имеют ярлык "enhancement".
|
||||
* Все известные проблемы лежат там же и имеют ярлык "bug".
|
||||
|
||||
Выбирайте задачи из ближайших версией. Их список вы можете найти [здесь](https://github.com/Rirusha/Cassette/milestones). Это как ускорит выход следующей версии, так и облегчит ревью, так так не нужно будет переключаться с одной глобальной проблемы на другую.
|
||||
|
||||
Также если решили исправить какой-то баг, описанный в issue, сначала убедитесь, что его всё ещё можно воспроизвести в `master` ветке.
|
||||
|
||||
Также, если вы считаете, что приложению чего-то не хватает или вы нашли баг, то не стесняйтесь создавать issue.
|
||||
|
||||
## Именование коммитов
|
||||
Заголовок сообщения должен иметь вид:
|
||||
```
|
||||
feat: добавить кнопку проигрывания в `Имя виджета`
|
||||
|
||||
Кнопки не хватало, поэтому её нужно было добавить
|
||||
```
|
||||
Это пример. Подробнее правила описаны [здесь](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional). Также тело сообщения необязательно, если информация в заголове исчерпывающая. Также вот список всех типов коммитов с описаниями:
|
||||
|
||||
* `build`: Используется для изменений, связанных с сборкой системы или внешними зависимостями.
|
||||
|
||||
* `chore`: Обычно включает в себя изменения, которые не относятся непосредственно к коду или тестам, например, обновление документации, настройка среды разработки, повышение версии и т. д.
|
||||
|
||||
* `ci`: Относится к изменениям, связанным с настройкой или улучшением CI.
|
||||
|
||||
* `docs`: Используется для изменений, касающихся только документации, например, исправления опечаток, обновление README или добавление комментариев в код.
|
||||
|
||||
* `feat`: Обозначает добавление новой функциональности или возможности в проект.
|
||||
|
||||
* `fix`: Относится к исправлению ошибок в коде или исправлению неполадок в проекте.
|
||||
|
||||
* `perf`: Используется, когда вносятся изменения с целью улучшения производительности.
|
||||
|
||||
* `refactor`: Относится к изменениям, которые не добавляют новую функциональность, а только изменяют структуру или организацию существующего кода.
|
||||
|
||||
* `revert`: Используется для отмены предыдущих коммитов в истории проекта.
|
||||
|
||||
* `style`: Относится к изменениям в форматировании кода, например, правки пробелов, отступов, переносов строк и т. д.
|
||||
|
||||
* `test`: Используется для добавления или изменения тестового кода, например, тестирование новой функциональности или исправление существующих тестов.
|
||||
|
||||
* `po`: Используется для добавления или изменения перевода.
|
||||
|
||||
## Создание Pull Request'ов
|
||||
Все Pull Request'ы должны быть сделанны в `master` ветку. Если вы закрываете какое-то issue, то ссылайтесь на него с ключевым словом "close" в теле коммита, например:
|
||||
```
|
||||
fix: исправить некорректное поведение
|
||||
|
||||
close #123
|
||||
```
|
||||
|
||||
## Форматирование кода
|
||||
Если вы используете Visual Studio Code, то есть таск для запуска линтера. Иначе используйте в линтере конфигурацию в корне репозитория: vala-lint.conf, CI использует именно её.
|
||||
|
||||
## Разработка
|
||||
Проверяйте сборку, используя flatpak, так как это единственная официально поддерживаемая версия.
|
||||
|
||||
## Тестирование
|
||||
Крайне приветствуется написание или дополнение существующих тестов для клиента.
|
||||
Loading…
Add table
Add a link
Reference in a new issue