Правила внесения вклада

Спасибо за ваш интерес к проекту Dapr!

Этот проект приветствует вклады и предложения. Большинство вкладов требуют от вас подписи ваших коммитов через Договор Разработчика (Developer Certificate of Origin, DCO). Когда вы отправляете запрос на слияние (pull request), бот DCO автоматически определяет, требуется ли вам предоставить подпись для вашего коммита. Пожалуйста, следуйте указаниям бота DCO, так как запросы на слияние не могут быть объединены до тех пор, пока автор(ы) не предоставят подпись для выполнения требования DCO. Вы можете найти больше информации о требованиях DCO ниже.

Этот проект принял Код поведения Contributor Covenant.

Вклад может принимать различные формы: создание проблем, написание кода, участие в обсуждениях и звонках сообщества.

Документ содержит руководства по тому, как вносить вклад в проект Dapr.

Проблемы

Эта секция описывает правила для создания проблем.

Типы проблем

Существует четыре типа проблем:- Проблема/Ошибка: Вы нашли ошибку в коде и хотите её сообщить, или создать проблему для отслеживания ошибки.

• Проблема/Обсуждение: У вас есть что сказать, которое требует обратной связи от других в рамках обсуждения перед тем, как это проявится в виде предложения.
• Проблема/Предложение: Используется для новых идей или функциональности. Это позволяет получить отзывы от других до того, как будет написан код.
• Проблема/Вопрос: Используйте этот тип проблемы, если вам нужна помощь или у вас есть вопрос.### Перед созданием проблемы

Перед созданием проблемы убедитесь, что вы проверили следующее:

1. Это правильный репозиторий?

   • Проект Dapr распределён по нескольким репозиториям. Если вы сомневаетесь в том, какой репозиторий является правильным, проверьте список репозиториев.

2. Проверка существующих проблем

   • Перед созданием новой проблемы, пожалуйста, выполните поиск в открытых проблемах, чтобы убедиться, что данная проблема или запрос на новую функцию ещё не был создан.
   • Если вы найдёте свою проблему уже существующей, сделайте соответствующие комментарии и добавьте вашу реакцию:
     • 👍 одобрение
     • 👎 неодобрение

3. Для багов

   • Убедитесь, что это не связано с проблемами окружения. Например, если вы работаете на Kubernetes, убедитесь, что все необходимые условия выполнены (хранители состояния, привязки и т.д.).
   • У вас должно быть как можно больше данных. Обычно это происходит в виде логов и/или трассировки стека. Если вы работаете на Kubernetes или другом окружении, просмотрите логи служб Dapr (runtime, operator, placement, scheduler service). Подробнее о том, как получить логи, можно найти здесь.1. Для предложений
   • Многие изменения в runtime Dapr могут требовать изменений в API. В этом случае лучшим местом для обсуждения потенциальной функции будет основной репозиторий Dapr.
   • Примеры могут включать привязки, хранилища состояний или полностью новые компоненты.## Внесение вклада в DaprЭтот раздел описывает руководства по внесению кода/документов в Dapr.

Пулл-запросы

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

1. Убедитесь, что есть открытое заявление (ошибка или предложение), которое устанавливает ожидания относительно вашего будущего вклада.
2. Создайте форк соответствующего репозитория и создайте новую ветку.
3. Примите ваши изменения.
   • Изменения кода требуют тестов.
4. Обновите соответствующую документацию (особенно справка по CLI: docs/reference) для ваших изменений.
5. Подтвердите изменения и откройте пулл-запрос.
6. Подождите завершения процесса CI и убедитесь, что все проверки прошли успешно.
7. Один из поддерживателей проекта будет назначен вам, и вы можете ожидать отзыва в течение нескольких дней.

Используйте пулл-запросы с пометкой WIP для раннего получения обратной связи

Хорошим способом общения до того, как вы вложите слишком много времени, является создание пулл-запроса с пометкой "Work-in-progress" (в разработке) и его предоставление вашим рецензентам. Стандартный метод заключается в добавлении префикса "[WIP]" в заголовок вашего пулл-запроса и присвоении метки do-not-merge. Это позволит людям, просматривающим ваш пулл-запрос, понять, что он ещё недостаточно доработан.### Сертификат участника разработки: Подписание вашего вклада

Каждый коммит должен быть подписан

Сертификат участника разработки (Developer Certificate of Origin, DCO) представляет собой легковесный способ для участников подтвердить, что они написали или иначе имеют право представить код, который они вносят в проект. Вот полный текст сертификата DCO, переформатированный для удобства чтения:

Подтверждая свой вклад в этот проект, я свидетельствую, что:

    (а) Вклад был создан полностью или частично мной и у меня есть право представить его под лицензией открытого программного обеспечения, указанной в файле;

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

(d) Я понимаю и соглашаюсь с тем, что этот проект и вклад являются общественными, а также то, что запись о вкладе (включая всю личную информацию, которую я предоставляю вместе с ним, в том числе мое подтверждение) будет храниться навечно и может быть redistributed в соответствии с условиями этого проекта или открытых лицензий, применимых к нему.```Конечные подписи участников, что они придерживаются этих требований, осуществляются путём добавления строки `Signed-off-by` в сообщении коммита.

Это мое сообщение коммита

Signed-off-by: Random J Developer <random@developer.example.org>

Git даже имеет командную строковую опцию -s, которая автоматически добавляет эту строку к вашему сообщению коммита:

$ git commit -s -m 'Это мое сообщение коммита'

Каждый запрос на вытягивание (pull request) проверяется на наличие действительной строки Signed-off-by в сообщении коммита.

Я не подписал свой коммит, что делать?

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

git checkout <branch-name>
git commit --amend --no-edit --signoff
git push --force-with-lease <remote-name> <branch-name>

Использование стороннего кода

• Все сторонние компоненты должны быть расположены в папке vendor/.
• Папка vendor/ управляема Go модулем и хранит исходный код сторонних зависимостей Go.
• Папка vendor/ не должна быть изменена вручную.
• Сторонний код должен содержать лицензии.

Неполный список кода, который должен быть размещен в vendor/:

• Открытые исходники, свободное программное обеспечение или коммерчески лицензированное программное обеспечение.
• Инструменты, библиотеки или протоколы, являющиеся открытыми исходниками, свободным программным обеспечением или коммерчески лицензированными.

## Код поведения

Данный проект принял [Код поведения Contributor Covenant](https://github.com/dapr/community/blob/master/CODE-OF-CONDUCT.md)