Вклад

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

Пожалуйста, ознакомьтесь с нашим Кодексом поведения перед внесением вклада.

Темы

• Вклад
  • Кодекс поведения
  • Темы
  • Сообщение о проблемах безопасности
  • Сообщение об общих проблемах
  • Внесение кода и документации
    • Подготовка рабочей области
    • Определение ветки
    • Правила фиксации
      • Сообщение фиксации
      • Содержание фиксации
    • Описание PR
  • Помощь в любом вопросе

Сообщение о проблемах безопасности

Мы серьёзно относимся к проблемам безопасности и призываем никого не распространять информацию о них. Если вы обнаружите проблему безопасности в KubeGateway, пожалуйста, не обсуждайте её публично и даже не создавайте публичную задачу. Вместо этого мы рекомендуем вам отправить нам личное сообщение по электронной почте kubewharf.conduct@bytedance.com, чтобы сообщить о проблеме безопасности.

Сообщение об общих проблемах

Любой пользователь может стать участником проекта. Если у вас есть какие-либо отзывы о проекте, смело создавайте задачу.

Поскольку разработка KubeGateway будет осуществляться распределённым образом, мы ценим ХОРОШО НАПИСАННЫЕ, ПОДРОБНЫЕ и ЯСНЫЕ отчёты о проблемах. Чтобы сделать общение более эффективным, мы предлагаем всем искать существующие проблемы перед созданием новой. Если вы считаете, что проблема уже существует, добавьте свои детали в комментарии к задаче.

Существует множество случаев, когда вы можете создать задачу:

• Отчёт об ошибке
• Запрос на функцию
• Проблемы с производительностью
• Предложение функции
• Дизайн функции
• Требуется помощь
• Неполная документация
• Улучшение теста
• Любые вопросы о проекте и так далее

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

Внесение кода и документации

Приветствуется любое действие, которое может улучшить KubeGateway. Это действие можно реализовать через PR (сокращение от запроса на вытягивание).

• Если вы найдёте опечатку, попробуйте исправить её!
• Если вы обнаружите ошибку, попробуйте исправить её!
• Если вы увидите избыточный код, попробуйте удалить его!
• Если вы заметите отсутствие тестовых случаев, попробуйте добавить их!
• Если вы сможете улучшить функцию, пожалуйста, НЕ СТЕСНЯЙТЕСЬ!
• Если код кажется вам неявным, попробуйте добавить комментарии, чтобы сделать его понятным!
• Если вы видите технические долги, попробуйте реорганизовать их!
• Если документация неверна, пожалуйста, исправьте это!

Невозможно перечислить их полностью, мы с нетерпением ждём ваших запросов на вытягивание. Прежде чем отправлять PR, мы рекомендуем ознакомиться с правилами PR здесь.

• Подготовка рабочей области
• Определение ветки
• Правила фиксации
• Описание PR

Подготовка рабочей области

Предполагается, что у вас уже есть учётная запись GitHub, тогда вы можете выполнить подготовку, выполнив следующие шаги:

1. ФОРК KubeGateway в свой репозиторий. Чтобы это сработало, вам просто нужно нажать кнопку «Форк» в правом верхнем углу главной страницы kube-gateway kube-gateway. Затем у вас появится ваш репозиторий по адресу https://github.com//kubegateway, где username — это ваш идентификатор GitHub.
2. КЛОНИРУЙТЕ свой собственный репозиторий для локальной разработки. Используйте git clone https://github.com/<username>/kubegateway.git, чтобы клонировать репозиторий на свой локальный компьютер. Затем вы можете создавать новые ветки, чтобы завершить изменения, которые вы хотите внести.
3. Установите удалённый апстрим как kube-gateway, используя следующие две команды:

git remote add upstream https://github.com/kubewharf/kubegateway.git
git remote set-url --push upstream no-pushing

С этой настройкой удалённого доступа вы можете проверить конфигурацию git удалённого следующим образом:

$ git remote -v
origin     https://github.com/<username>/kubegateway.git (fetch)
origin     https://github.com/<username>/kubegateway.git (push)
upstream
``` **Текст запроса:**

https://github.com/kubewharf/kubegateway.git (fetch)
upstream   no-pushing (push)

With above, we can easily synchronize local branches with upstream branches.

Branch Definition

Right now we assume every contribution via pull request is for the master branch in KubeGateway. There are several other branches such as rc branches, release branches and backport branches. Before officially releasing a version, we may checkout a rc (release candidate) branch for more testings. When officially releasing a version, there may be a release branch before tagging which will be deleted after tagging. When backporting some fixes to existing released version, we will checkout backport branches.

Commit Rules

In KubeGateway, we take two rules seriously for submitted PRs:

• Commit Message
• Commit Content

Commit Message

TODO

Commit Content

TODO

PR Description

PR is the only way to make change to KubeGateway project. To help reviewers, we actually encourage contributors to make PR description as detailed as possible.

Engage to help anything

GitHub is the primary place for KubeGateway contributors to collaborate. Although contributions via PR is an explicit way to help, we still call for any other types of helps.

• Reply to other's issues if you could;
• Help solve other user's problems;
• Help review other's PR design;
• Help review other's codes in PR;
• Discuss about KubeGateway to make things clearer;
• Advocate KubeGateway technology beyond GitHub;
• Write blogs on KubeGateway, and so on.

In a word, ANY HELP CAN BE A CONTRIBUTION.

Перевод текста запроса на русский язык:

С помощью вышеуказанного мы можем легко синхронизировать локальные ветки с вышестоящими ветками.

Определение веток

Сейчас мы предполагаем, что каждый вклад через запрос на вытягивание (pull request) предназначен для ветки master в KubeGateway. Существует несколько других веток, таких как ветки rc, ветки релиза и ветки бэкпорта. Перед официальным выпуском версии мы можем проверить ветку rc (кандидата на выпуск) для дополнительных тестов. При официальном выпуске версии может существовать ветка релиза перед тегами, которая будет удалена после тегирования. Когда мы портируем некоторые исправления в существующую выпущенную версию, мы проверяем ветки бэкпорта.

Правила коммита

В KubeGateway мы серьёзно относимся к двум правилам для представленных PR:

• Сообщение коммита (#commit-message).
• Содержание коммита (#commit-content).

Сообщение коммита

TODO.

Содержание коммита

TODO.

Описание PR

PR — это единственный способ внести изменения в проект KubeGateway. Чтобы помочь рецензентам, мы действительно призываем участников делать описание PR максимально подробным.

Участвуйте, чтобы помочь

GitHub — основное место для совместной работы участников KubeGateway. Хотя вклад через PR — явный способ помочь, мы всё ещё призываем к любой другой помощи.

• Отвечайте на чужие проблемы, если можете;
• Помогайте решать проблемы других пользователей;
• Помогите проверять дизайн чужих PR;
• Проверьте код в PR;
• Обсудите KubeGateway, чтобы сделать вещи понятнее;
• Продвигайте технологию KubeGateway за пределами GitHub;
• Пишите блоги о KubeGateway и так далее.

Одним словом, ЛЮБАЯ ПОМОЩЬ МОЖЕТ БЫТЬ ВКЛАДОМ.