Вклад в проект

Введение

В большинстве случаев мы используем репозиторий KubeVela для обсуждения функций или вклада кода. Репозиторий модели в основном предназначен для планирования выпуска и обсуждения на высоком уровне (например, предложение новой сущности в модели).

Предложение изменений и политика LGTM

Предложение изменения в Open Application Model означает предложение изменения API в проекте KubeVela. Пожалуйста, всегда сначала обсуждайте изменение в репозитории KubeVela и переносите обсуждение сюда только тогда, когда изменение является фундаментальным и значительным.

Затем откройте вопрос в очереди вопросов перед отправкой запроса на вытягивание (PR). Все PR должны быть проверены и одобрены (LGTMed) двумя сопровождающими перед объединением. Сопровождающие указаны в файле OWNERS. Обратитесь к руководству по вкладу в этот документ для получения более подробной информации о процессе работы с вопросами и PR.

Кодекс поведения

Этот проект принял кодекс поведения Contributor Covenant (code-of-conduct.md/). Пожалуйста, поддерживайте уважительное общение в очереди вопросов, очереди PR и всех других каналах связи.

Руководство по внесению вклада

Этот репозиторий принимает вклады через запросы на вытягивание GitHub. В следующем разделе описывается процесс объединения вкладов в спецификацию.

Вопросы

Вопросы используются в качестве основного метода отслеживания всего, что связано с проектом Open Application Model.

Жизненный цикл вопроса

Все типы вопросов следуют одному и тому же общему жизненному циклу. Различия указаны ниже.

1. Создание вопроса.
2. Триггер:
   • Ответственный за триггер сопровождающий применит соответствующие метки к вопросу. Это включает в себя метки приоритета, типа и метаданных.
   • (При необходимости) Очистите заголовок, чтобы кратко и чётко сформулировать проблему. Также убедитесь, что предложения начинаются со слова «Предложение».
   • Мы стараемся делать это хотя бы раз в рабочий день.
3. Обсуждение:
   • Вопросы «Изменение спецификации» должны быть связаны с PR, который их решает.
   • Тот, кто работает над вопросом «Изменение спецификации», должен либо назначить вопрос себе, либо сделать комментарий в вопросе, говорящий, что он его берёт.
   • Вопросы «Предложение» и «Обсуждение» должны оставаться открытыми до разрешения.
4. Закрытие вопроса.

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

Мы используем запросы на вытягивание (PR), чтобы отслеживать изменения кода. Чтобы внести изменение в проект:

1. Создайте форк репо, измените проект, чтобы решить проблему.
2. Выберите открытый вопрос из списка вопросов (https://github.com/oam-dev/spec/issues) и заявите об этом в комментариях. После одобрения исправьте проблему и отправьте нам запрос на вытягивание (PR).
3. Или вы можете создать новый вопрос. Участник сообщества ответит вам, и, если будет одобрено, вы сможете исправить проблему и отправить запрос на вытягивание.
4. Пожалуйста, сначала просмотрите наш список вопросов (открытых и закрытых) и убедитесь, что проблема, о которой вы сообщаете, не дублирует уже сообщённую проблему. Если у вас есть вопросы на нескольких страницах, сообщите о них отдельно. Не объединяйте их в один вопрос.
5. Отправьте запрос на вытягивание в соответствующую ветку.

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

Жизненный цикл PR

1. Создание PR:
   • Мы приветствуем PR, которые находятся в процессе выполнения. Они являются отличным способом отслеживать важную работу, которая находится в стадии разработки, но полезна для просмотра другими. Если PR находится в разработке, он должен начинаться со слов «WIP: [название]». Вы также должны добавить метку wip. После того как PR будет готов к рассмотрению, удалите «WIP» из заголовка и метки.
   • Предпочтительно, но не обязательно, иметь PR, связанный с конкретным вопросом. Могут быть обстоятельства, при которых, если это быстрое исправление, вопрос может быть излишним. Подробности, представленные в описании PR, будут достаточными в этом случае.
2. Триггер:
   • Сопровождающий, ответственный за триггер, применит надлежащие метки к проблеме. Сюда должно входить как минимум метка размера, веха и ожидание проверки после применения всех меток. См. раздел «Метки» для получения полной информации об определениях меток.
3. Проверка/обсуждение:
   • Все проверки будут проводиться с использованием... Выполните следующую команду:

git rebase -i origin/master~n master(имея n количество коммитов).

12. После выполнения команды git rebase -i откроется текстовый редактор с файлом, в котором перечислены все коммиты текущей ветки, и перед каждым коммитом стоит слово «pick». Для каждой строки, кроме первой, замените слово «pick» на слово «squash».

13. Сохраните и закройте файл, и через мгновение в редакторе должен появиться новый файл, объединяющий все сообщения коммитов всех коммитов. Переформулируйте это сообщение коммита в содержательное, кратко объясняющее все функции, а затем также сохраните и закройте этот файл. Это сообщение коммита будет сообщением коммита для одного большого коммита, который вы объединяете все свои большие коммиты. Как только вы сохранили и закрыли этот файл, ваши коммиты в текущей ветке были объединены вместе.

14. Принудительно отправьте обновление вашего запроса на извлечение с помощью команды git push origin branchname --force.