Вклад в Nacos

Добро пожаловать в Nacos! Этот документ представляет собой руководство о том, как внести свой вклад в Nacos.

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

Прежде чем начать

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

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

Вклад

Nacos приветствует новых участников любой роли, включая пользователя, участника, коммиттера и PMC.

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

Откройте / возьмите на себя задачу для подготовки

Если вы обнаружили опечатку в документе, нашли ошибку в коде или хотите предложить новые функции, вы можете открыть вопрос на GitHub, чтобы сообщить об этом.

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

• Contribution Welcome: Сильно необходимая задача, но в настоящее время не хватает рук.

• good first issue: Подходит для новичков, новички могут выбрать одну для разминки.

Мы придаём большое значение документации и интеграции с другими проектами, такими как Spring Cloud, Kubernetes, Dubbo и т. д. Мы очень рады работать над любыми задачами в этих аспектах.

Обратите внимание, что любой PR должен быть связан с действительной задачей. В противном случае PR будет отклонён.

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

Теперь, если вы хотите внести свой вклад, создайте новый запрос на вытягивание.

Мы используем ветку develop в качестве ветки разработки, которая указывает на то, что это нестабильная ветка.

Кроме того, наша модель ветвления соответствует https://nvie.com/posts/a-successful-git-branching-model/. Мы настоятельно рекомендуем новичкам ознакомиться с приведённой выше статьёй перед созданием PR.

Теперь, если вы готовы создать PR, вот рабочий процесс для участников:

1. Форкните себе.

2. Клонируйте форк в локальный репозиторий.

3. Создайте новую ветку и работайте над ней.

4. Поддерживайте свою ветку в актуальном состоянии.

5. Зафиксируйте свои изменения (убедитесь, что ваше сообщение о фиксации краткое).

6. Отправьте свои коммиты в свой разветвлённый репозиторий.

7. Создайте запрос на вытягивание в ветку develop.

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

1. Пожалуйста, следуйте шаблону запроса на вытягивание.

2. Пожалуйста, создайте запрос в ветке develop.

3. Убедитесь, что PR имеет соответствующую задачу.

4. Если ваш PR содержит большие изменения, например, рефакторинг компонента или новые компоненты, напишите подробные документы о его дизайне и использовании.

5. Обратите внимание, что один PR не должен быть слишком большим. Если требуются серьёзные изменения, лучше разделить изменения на несколько отдельных PR.

6. После создания PR одному или нескольким рецензентам будет назначен запрос на вытягивание.

7. Перед объединением PR объедините любые отзывы рецензентов по исправлению, опечатки, объединённые и перебазированные типы коммитов. Окончательное сообщение о коммите должно быть ясным и кратким.

Если ваш PR содержит большие изменения, например, рефакторинг компонентов или новые компоненты, пожалуйста, напишите подробные документы об их дизайне и использовании.

Руководство по проверке кода

Коммиттеры будут по очереди проверять код, чтобы убедиться, что все PR будут проверены своевременно и хотя бы одним коммиттером перед слиянием. Если мы не выполняем свою работу (иногда мы что-то упускаем). И, как всегда, мы приветствуем добровольцев для проверки кода.

Некоторые принципы:

• Читаемость — важный код должен быть хорошо документирован. API должен иметь Javadoc. Стиль кода должен соответствовать существующему.

• Элегантность: Новые функции, классы или компоненты должны быть хорошо спроектированы.

• Тестируемость — 80 % нового кода должно быть покрыто модульными тестовыми примерами.

• Сопровождаемость — соответствует нашему PMD. А теперь, как насчёт того, чтобы попробовать стать коммиттером?

В общем, внесите 8 нетривиальных патчей и получите как минимум трёх разных людей для их проверки (вам понадобятся три человека, которые вас поддержат). Затем попросите кого-нибудь выдвинуть вашу кандидатуру. Вы демонстрируете:

• как минимум 8 PR и связанные с ними проблемы проекта;
• способность сотрудничать с командой;
• понимание кодовой базы проектов и стиля кодирования;
• умение писать хороший код (последнее, но не менее важное).

Текущий коммиттер выдвигает вашу кандидатуру, сообщая команде о проблеме Nacos с пометкой «выдвижение».

Он предоставляет:

• ваше имя и фамилию;
• ссылку на ваш профиль Git;
• объяснение, почему вы должны быть коммиттером;
• подробную информацию о трёх лучших PR и связанных с ними проблемах, над которыми номинатор работал с вами и которые могут продемонстрировать ваши способности.

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

В худшем случае это может затянуться на две недели. Продолжайте вносить свой вклад! Даже в редких случаях, когда выдвижение кандидатуры не удаётся, возражение обычно связано с чем-то легко решаемым, например, «больше патчей» или «недостаточно людей знакомы с работой этого человека».