Как внести свой вклад

Для получения более подробной информации посетите официальный сайт Как вносить вклад в проект

Большое спасибо за ваш вклад в проект Linkis! Перед тем как приступить к внесению своего вклада, пожалуйста, внимательно ознакомьтесь с следующими руководствами.

1. Категория вклада

1.1 Отзывы о багах и исправления

Мы рекомендуем создать задачу для детального описания бага, независимо от того, является ли это отзывом о баге или исправлением. Это позволит сообществу найти и проверить проблему через запись задачи. Задачи отзывов о багах обычно должны содержать полное описание бага и повторяемую ситуацию, чтобы сообщество могло быстро локализовать причину бага и его исправить. Все открытые задачи, содержащие тэг #bug, требуют исправления.

1.2 Функциональное взаимодействие, реализация, рефакторингВ процессе взаимодействия, подробное описание механизмов и сценариев использования новой функции (или рефакторинга) способствует лучшей и быстрой реализации (включая тестовые случаи и коды, а также работу CI/CD). Если вы планируете реализовать крупную функцию (или рефакторинг), обязательно свяжитесь с основной командой разработчиков через задачу или другими средствами, чтобы все могли продвигаться наиболее эффективным образом. Задачи, отмеченные тэгом #feature, являются всеми новыми функциями, которые требуется реализовать, а задачи, отмеченные тэгом #enhancement, являются всеми функциями, которые требуют улучшения и рефакторинга.### 1.3 Вопросы и ответы по задачам

Помощь в ответах на вопросы в сообществе Linkis — очень ценная форма участия; всегда будут новые пользователи, которые продолжают приходить в сообщество. Помогая новым пользователям, вы можете показать свои знания.

1.4 Уточнение документации

Вы можете найти документацию Linkis на сайте linkis-Website, и дополнение к документации также важно для развития Linkis.

1.5 Другое

Включает участие в организации и помощи в проведении обменов сообщества, операционных мероприятий сообщества и других мероприятий, которые могут помочь проекту Linkis и сообществу.

2. Как вносить вклад

2.1 Структура веток

Исходный код Linkis может содержать некоторые временные ветки, но только следующие три ветки действительно имеют значение:

• master: исходный код последней стабильной версии, а также иногда несколько патчей;
• release-*: стабильная версия выпуска;
• dev-*: основная ветка развития;

2.1.1 Концепция

• Ветка Upstream: https://github.com/apache/linkis Ветка Upstream называется репозиторием Apache linkis в тексте
• Ветка Fork: от https://github.com/apache/linkis форкнутая в ваш личный репозиторий, который называется Fork репозиторием

2.1.2 Обновление Upstream репозитория

Обновите самую свежую версию кода ветки Upstream репозитория в вашем личном Fork репозитории- Шаг 1: Перейдите на страницу проекта пользователя и выберите ветку для обновления.

• Шаг 2: Нажмите кнопку "Fetch upstream" под кнопкой загрузки кода, выберите "Fetch and merge" (если ветка вашего Fork репозитория случайно была загрязнена, вы можете удалить ветку и синхронизировать новую ветку Upstream репозитория в вашем Fork репозитории, см. руководство [Синхронизация Upstream]). Самую свежую версию кода ветки Upstream репозитория в свой Fork репозиторий) (#213-синхронизация новой ветки Upstream репозитория в свой Fork репозиторий).

2.1.3 Синхронизация новой ветки

Синхронизируйте новую ветку Upstream репозитория в вашем Fork репозитории.

Сценарий: В Upstream репозитории есть новая ветка, но Fork репозиторий её ещё не имеет (вы можете выбрать удаление и повторное форкирование, но изменения, которые ещё не были слиты в Upstream репозиторий, будут потеряны).

Работайте в своей локальной копии проекта:

• Шаг 1: Добавьте образ репозитория apacheUpstream в локальную систему.

git remote add apache git@github.com:apache/linkis.git

• Шаг 2: Получите информацию об образе apache в локальную систему.

git fetch apache

• Шаг 3: Создайте локальную ветку на основе новой ветки, которую требуется синхронизировать.

git checkout -b dev-1.1.4 apache/dev-1.1.4
```- Шаг 4: Отправьте локальную ветку в ваш репозиторий. Если ваш репозиторий ещё не имеет ветки `dev-1.1.4`, она будет создана.```shell script
git push origin dev-1.1.4:dev-1.1.4
```- Шаг 5 Удалите ветку upstream

```shell script
git remote remove apache

• Шаг 6 Обновите ветку

git pull

2.1.4 Процесс создания Pull Request (PR)

• Шаг 1 Подтвердите основную ветку текущего развития (обычно это текущая версия в процессе разработки, такая как версия 1.1.0, которая находится в разработке сообществом, тогда ветка будет dev-1.1.0; если вы не уверены, вы можете спросить в группе сообщества или обратиться к @соответствующим одноклассникам в задаче).

• Шаг 2 Синхронизируйте последний код ветки Upstream с вашей веткой Fork, см. руководство [2.1.2 Синхронизация Upstream Repository].

• Шаг 3 На основе основной ветки вытяните новую ветку с исправлениями/функциями (не модифицируйте её напрямую на оригинальной ветке, если следующий PR будет объединён методом squash, записи отправленных коммитов будут объединены в один).

git checkout -b dev-1.1.4-fix dev-1.1.4
git push origin dev-1.1.4-fix:dev-1.1.4-fix

• Шаг 4 Разработка
• Шаг 5 Отправьте PR (если он ещё находится в процессе и разработка ещё не завершена полностью, пожалуйста, добавьте логотип WIP в название PR, например [WIP] Dev 1.1.1 Добавление тестового кода JUnit для [linkis-common]; ассоциируйте соответствующую задачу и т.д.).
• Шаг 6 Ожидание слияния
• Шаг 7 Удалите ветку с исправлениями/будущими изменениями (вы можете сделать это на странице GitHub).

git branch -d dev-1.1.4-fix
git push
```Пожалуйста, обратите внимание: Для основной ветки крупных функциональностей помимо номера версии будет добавлено соответствующее описание названия, например: dev-0.10.0-flink, что указывает на ветку разработки функциональности Flink версии 0.10.0.

### 2.2 Руководства по разработке

Код переднего и заднего плана Linkis используют одну базу кода, но они разделены при разработке. Перед началом работы сделайте форк проекта Linkis в ваши репозитории GitHub и работайте на основе базы кода Linkis в ваших репозиториях GitHub.

Мы рекомендуем клонировать ветку `dev` и называть её `dev-fix` для разработки. В то же время создайте новую ветку `dev-fix` в вашем репозитории и модифицируйте её напрямую на оригинальной ветке. Если следующий PR будет объединён методом squash, записи отправленных коммитов будут объединены в один.

```shell script
# Выполните клонирование ветки
git clone https://github.com/{githubid}/linkis.git --branch dev

# Создайте локальную ветку dev-fix на основе ветки dev
git checkout -b dev-fix dev

# Отправьте локальную ветку dev-fix в свой собственный репозиторий
git push origin dev-fix dev-fix

2.3 Правила подачи проблем (Issues)- Если вы всё ещё не знаете, как запустить запрос на слияние (PR) в открытом проекте, обратитесь к разделу О проблемах

• Название проблемы должно кратко описать вашу проблему или предложение одним предложением; для международной пропаганды проекта, пожалуйста, пишите проблему на английском языке или на обоих — английском и китайском

• Для каждой проблемы, пожалуйста, прикрепите хотя бы две метки, компонент и тип, такие как component=Computation Governance/EngineConn, type=Improvement. Пример: проблема #590### 2.4 Правила подачи запросов на слияние (Pull Requests)

• Если вы всё ещё не знаете, как запустить PR в открытом проекте, обратитесь к разделу О запросах на слияние. Независимо от того, является ли это исправлением ошибки или разработкой нового функционала, пожалуйста, отправьте PR в ветку dev-*.

• Имя PR следует принципу <тип>(<범위>): <тема>, подробнее см. Руководство по написанию сообщений о коммитах и изменениях.

• Если PR содержит новые функции, обновление документации должно быть включено в этот PR.

• Если этот PR ещё не готов к слиянию, пожалуйста, добавьте префикс [WIP] в начало имени (WIP = работа в процессе).

• Все подачи в ветки dev-* должны пройти как минимум одну проверку перед тем, как будут слиты.

2.5 Критерии проверки

Перед подачей кода, вы можете узнать, какие виды подач наиболее популярны в проверках. Вкратце говоря, если подача может принести максимальную пользу с минимальными побочными эффектами или рисками, вероятность её слияния будет выше, а проверка будет быстрее. Подачи с высокими рисками и низкими ценностью почти невозможно слить, они могут быть отклонены проверками.#### 2.5.1 Преимущества

• Устраните основную причину бага
• Добавьте или исправьте функцию или проблему, которую большинство пользователей срочно требует
• Простое и эффективное решение
• Легко тестировать, с примерами тестовых случаев
• Уменьшите сложность и объём кода
• Вопросы, которые были обсуждены сообществом и выделены для улучшения

2.5.2 Взаимодействие побочных эффектов и рисков- Устраняет только проявление поверхности бага

• Вводит новые сложные функции
• Добавляет сложность для удовлетворения специфических потребностей
• Изменяет стабильное существующее API или семантику
• Приводит к некорректной работе других функций
• Добавляет большое количество зависимостей
• Изменяет версию зависимости произвольно
• Подаёт большой объём кода или изменений за один раз

2.5.3 Примечания рецензента

• Пожалуйста, используйте конструктивный тон при написании комментариев
• Если вам требуется внести изменения от лица отправителя, пожалуйста, четко укажите все содержание, которое требует модификации для завершения запроса Pull Request
• Если после слияния PR выявлены новые проблемы, рецензент должен связаться с автором PR и сообщить о необходимости решения проблемы; если автор PR недоступен, рецензент должен восстановить PR

3. Выдающиеся участники

3.1 О Committer'ах (Сотрудниках)

3.1.1 Как стать Committer'омЕсли вы представили ценный Pull Request для проекта Linkis и он был принят, либо постоянно вносите вклад более чем полгода, а также возглавляли выпуск хотя бы одной версии, вы можете найти PMC проекта Linkis через официальную группу WeChat, если он согласен выдвигать вас в качестве Committer'а, и готов заявить о вашем вкладе перед всеми PMC и Committer'ами, тогда будет запущено голосование; PMC и другие Committer'ы будут совместно голосовать, чтобы решить, следует ли допустить вас к участию; если вы наберёте достаточно голосов, вы станете Committer'ом проекта Linkis.#### 3.1.2 Права Committer'а

• Вы можете присоединиться к официальному чату разработчиков WeChat для участия в обсуждении и формировании планов развития Linkis
• Может управлять Issue'ами, включая закрытие и добавление меток
• Может создавать и управлять ветками проекта, за исключением основной ветки master и веток dev-*
• Вы можете проверять Pull Request'ы, поданные в ветки dev-*
• Может подать заявку на участие в Комитете

3.2 О Комитете

3.2.1 Как стать членом Комитета

Если вы являетесь Committer'ом проекта Linkis, и все ваши вклады были признаны другими членами Комитета, вы можете подать заявку на вступление в Комитет проекта Linkis, и другие члены Комитета будут совместно голосовать, чтобы решить, следует ли допустить вас к участию. Если вы получите единогласное одобрение, вы станете членом Комитета проекта Linkis.

3.2.2 Права членов комитета

• Вы можете объединять запросы на слияние (PR), отправленные другими Committer'ами и участниками в dev-* ветку
• Участвовать в определении дорожной карты и направлений развития проекта Linkis
• Вправе участвовать в выпуске новой версии