Вклад в Nocalhost

Signed-off-by: Tom <tom@example.com>
```В большинстве случаев вы можете автоматически добавить эту подпись к вашему коммиту с помощью флага `-s` или `--signoff` к `git commit`. Вы должны использовать свое настоящее имя и доступный адрес электронной почты (извините, псевдонимы или анонимные вклады недопустимы). Пример подписи коммита:

### Типы проблемСуществует 5 типов проблем (каждый со своим соответствующим [меткой](#labels)):

- `question/поддержка`: Эти запросы или запросы функциональности, которые мы хотим иметь в виде записи для будущего использования. Обычно это вопросы, которые слишком сложны или объемны для хранения в канале Slack или имеют особый интерес для всего сообщества. В зависимости от обсуждения, они могут превратиться в `функциональность` или `ошибку`.
- `предложение`: Используется для элементов (как в этом случае), которые предлагают новые идеи или функциональность, требующую более широкого обсуждения в сообществе. Это позволяет получить обратную связь от других участников сообщества до того, как функциональность будет разработана. Это не требуется для небольших добавлений. Окончательное решение о том, нуждается ли функциональность в предложении, принимается ядром поддержки. Все запросы, являющиеся предложениями, должны иметь и метку, и заголовок "Предложение: [остальная часть заголовка]".
- `функциональность`: Эти запросы отслеживают конкретные запросы на функциональность до тех пор, пока они не будут завершены. Они могут развиваться из `предложения` или могут быть поданы отдельно в зависимости от размера.
- `ошибка`: Эти запросы отслеживают ошибки в коде.
- `документация`: Эти запросы отслеживают проблемы с документацией (например, отсутствие или неполные данные).

### Цикл жизни задачЦикл жизни задач в основном управляемый ядром поддержки, но это полезная информация для тех, кто вносит вклад в Nocalhost. Все типы задач следуют общему циклу жизни. Различия отмечены ниже.1. Создание задачи
2. Сортировка задач
	- Ответственный за поддержку, занимающийся сортировкой задач, должен применить соответствующие метки для задачи. Это включает метки для приоритета, типа и метаданных (например, `good first issue`). Единственным приоритетом задачи, который мы будем отслеживать, является то, является ли задача "критической". Если в будущем потребуются дополнительные уровни приоритета, мы добавим их.
	- (Если необходимо) Убедитесь, что заголовок задачи краток и ясен. Также убедитесь, что предложения начинаются со слова "Proposal: [остальная часть заголовка]".
	- Добавьте задачу в соответствующий майлстоун. Если возникнут вопросы, не беспокойтесь о добавлении задачи в майлстоун до тех пор, пока вопросы не будут решены.
	- Мы стараемся выполнять этот процесс по крайней мере один раз в рабочий день.
3. Обсуждение
	- Задачи, отмеченные как `feature` или `proposal`, должны иметь документ Nocalhost Improvement Proposal (NIP: В разработке). Мелкие улучшения качества жизни исключены.
	- Задачи, отмеченные как `feature` или `bug`, должны быть связаны с PR, который их решает.
	- Кто бы ни работал над задачей `feature` или `bug` (будь то поддержка или участник сообщества), должен либо назначить задачу себе, либо оставить комментарий в задаче, что он берет её в работу.
	- Задачи `proposal` и `support/question` должны оставаться открытыми до тех пор, пока они не будут решены или если они не активны более 30 дней.Это поможет поддерживать список задач в управляемом размере и уменьшить шум. Если задача должна оставаться открытой, метка `keep open` может быть добавлена.
4. Закрытие задачи## Внесение изменений (Pull Requests)
Мы с радостью принимаем ваши внесения изменений, чтобы сделать Nocalhost лучше.

### Управление ветками
Здесь есть две основные ветки:

1. Ветка `main`.
	1. Это последняя (пред-)релизная ветка. Мы используем `main` для тегов с номерами версий `v0.4.10`, `v0.4.12` ...
	2. **Не отправляйте никакие PR на ветку `main`.**
2. Ветка `dev`.
	1. Это наша стабильная разработочная ветка. После полного тестирования `dev` будет объединена с веткой `main` для следующего релиза.
	2. **Вам рекомендуется отправлять PR с исправлениями ошибок или новыми функциями на ветку `dev`.** Обычные исправления ошибок или запросы на добавление новых функций должны быть отправлены в ветку `dev`. После полного тестирования мы будем объединять их в ветку `main` для следующего релиза.

### Как внести патч

1. Определите или создайте связанное с этим сообщение об ошибке.
2. Создайте форк нужного репозитория; разработайте и протестируйте изменения в коде.
3. Отправьте запрос на слияние, убедившис Yö что вы подпишете свою работу и привяжете к связанному сообщению об ошибке.

Стандарты и соглашения для коммитов объясняются в [документации по спецификации коммитов](https://github.com/nocalhost/nocalhost/blob/main/docs/contribute/commit-specification.md).### Создание запросов на слияние
Команда разработчиков будет отслеживать все запросы на слияние, мы проведем некоторые проверки кода и тесты. После успешного прохождения всех тестов, мы примем этот запрос на слияние. Однако он не будет сразу объединен в ветку `main`, что может занять некоторое время.Перед отправкой запроса на слияние, убедитесь, что выполнены следующие шаги:

1. Создайте форк репозитория и создайте свою ветку из `main`.
2. Обновите код или документацию, если вы изменили API.
3. Добавьте уведомление об авторских правах в начале любых новых файлов, которые вы добавили.
4. Проверьте, соответствует ли ваш код стандартам форматирования и стилей.
5. Тестируйте и ещё раз протестируйте ваш код.
6. Теперь вы можете отправить запрос на слияние на ветку `dev`.### Жизненный цикл запроса на слияние

1.   Создание запроса на вытягивание (Pull Request, PR)
  	- PR обычно создаются для исправления или являются подмножеством других PR, которые исправляют определённую проблему.
  	- Мы более чем приветствуем PR, которые находятся в процессе.  Они являются отличным способом отслеживания важной работы, которая находится в процессе, но полезны для других для просмотра.  Если PR является работой в процессе, он **должен** быть предварён "WIP: [название]".  Как только PR готов для проверки, убирают "WIP" из названия.
  	- Просьба иметь PR, привязанный к определённой проблеме, но это не обязательно.  В некоторых случаях, если это быстрое исправление, проблема может быть излишней.  В этом случае достаточно деталей, предоставленных в описании PR.
  2.   Сортировка (Triage)
  	- Управляющий, ответственный за сортировку, примет соответствующие метки для проблемы.  Это должно включать по крайней мере `баг` или `функциональность`, и `ожидает проверки` после того, как все метки применены.  См.  [раздел Меток](#labels) для полной информации о метках.
  3.   Назначение проверок
  	- Как только проверка имеет метку `ожидает проверки`, управляющие будут проверять их по мере возможности.  Управляющий, который берёт проблему, должен сам запросить проверку.
  4.   Проверка/Обсуждение
  	- Все проверки будут выполнены с помощью инструмента проверки GitHub.  - "Комментарий" проверка должна быть использована, когда есть вопросы о коде, которые должны быть ответами, но которые не включают изменения кода. Этот тип проверки не считается одобрением.
  - "Требуются изменения" проверка указывает, что изменения в коде должны быть сделаны перед тем, как они будут объединены.
  - Проверяющие должны обновлять метки по мере необходимости (например, `требуется перебазирование`).
  5. Ответить на комментарии, отвечая на вопросы или изменяя код
  6. LGTM (Looks good to me)
  	- Как только проверяющий завершит проверку и код будет готов к объединению, используется "Одобрить" проверка для сигнализации владельцу PR и другим управляющим, что вы проверили код и считаете его готовым к объединению.
  7. Объединение или закрытие
  	- PR должны оставаться открытыми до объединения или если они не активны более 30 дней. Это поможет поддерживать список PR в управляемом размере и уменьшить шум. В случае, если PR должен оставаться открытым (например, в случае WIP), метка `оставить открытым` может быть добавлена.
  	- Если владелец PR указан в файле `OWNERS`, этот пользователь **должен** объединить свои собственные PR или явно запросить другого OWNER сделать это за него. - Если владелец запроса на слияние (PR) _не_ указан в файле `OWNERS`, любой ядрёный поддерживатель может слить этот PR. #### Документация PRsДокументационные PRs будут следовать той же жизненной цикл, что и другие PRs. Они также будут помечены меткой
`docs`. Для документации особое внимание будет уделено орфографии, грамматике и ясности (в отличие от комментариев в коде, где эти вещи не столь важны).

## Триажер

Каждый месяц один из основных поддерживателей будет выполнять роль "триажера" после публичных собраний в четверг. Этот человек будет отвечать за сортировку новых PRs и проблем в течение рабочей недели.

## Метки

Следующие таблицы определяют все типы меток, используемые для Nocalhost. Они разделены по категориям.

### Общие

| Метка | Описание |
| ----- | ----------- |
| `bug` | Помечает проблему как ошибку или PR как исправление ошибки |
| `critical` | Помечает проблему или PR как критическую. Это означает, что решение PR или проблемы является первостепенной задачей и должно быть выполнено как можно скорее |
| `docs` | Указывает, что проблема или PR является изменением документации |
| `feature` | Помечает проблему как запрос на новую функцию или PR как реализацию новой функции |
| `keep open` | Указывает, что проблема или PR должна оставаться открытой более  Yöntem 30 дней без активности |
| `refactor` | Указывает, что проблема является переработкой кода и не является исправлением ошибки или добавлением новой функциональности |

Продолжение:

### Общие

| Метка | Описание |
| ----- | ----------- |
| `bug` | Помечает проблему как ошибку или PR как исправление ошибки |
| `critical` | Помечает проблему или PR как критическую. Это означает, что решение PR или проблемы является первостепенной задачей и должно быть выполнено как можно скорее |
| `docs` | Указывает, что проблема или PR является изменением документации |
| `feature` | Помечает проблему как запрос на новую функцию или PR как реализацию новой функции |
| `keep open` | Указывает, что проблема или PR должна оставаться открытой более 30 дней без активности |
| `refactor` | Указывает, что проблема является переработкой кода и не является исправлением ошибки или добавлением новой функциональности |### Специфические для проблемы

| Метка | Описание |
| ----- | ----------- |
| `help wanted` | Помечает проблему, которая требует помощи от сообщества |
| `proposal` | Помечает проблему как предложение |
| `question/support` | Помечает проблему как запрос на поддержку или вопрос |
| `good first issue` | Помечает проблему как хорошую начальную проблему для новичков в Nocalhost |
| `wont fix` | Помечает проблему как обсужденную и не требующую исправления (или не принимаемую в случае предложения) |

### Специфические для PR

| Метка | Описание |
| ----- | ----------- |
| `awaiting review` | Указывает, что PR был отсортирован и готов к проверке |
| `breaking` | Указывает, что PR содержит изменения, нарушающие совместимость (например, изменения в API) |
| `in progress` | Указывает, что поддерживатель рассматривает PR, даже если еще не было проведено обзора |
| `needs rebase` | Указывает, что PR требует перебазирования перед слиянием |
| `needs pick` | Указывает, что PR требует переноса ветки функций (обычно ветки исправлений ошибок). После переноса метка `picked` должна быть применена, а эта метка удалена |
| `picked` | Этот PR был перенесен в ветку функций |

## Лицензия
Принимая участие в проекте Nocalhost, вы соглашаетесь с тем, что ваши вклады будут лицензированы в соответствии с его [Apache 2.0 LICENSE](./LICENSE)