Руководящие принципы для коммитеров (для лиц с правами коммита в Ansible на GitHub)

Данные руководящие принципы предназначены для лиц с правами коммита в Ansible. Коммитеры по сути являются членами ядра Ansible, хотя и не обязательно сотрудниками Ansible и Red Hat. Пожалуйста, ознакомьтесь с данными принципами перед коммитом.

Эти руководящие принципы применимы ко всем. В то же время, это НЕ документ процесса. Поэтому просто воспользуйтесь здравым смыслом. Вам предоставлен доступ к коммитам, поскольку мы доверяем вашему суждению.

При этом используйте это доверие мудро.

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

Функции, высокоуровневое проектирование и дорожная карта

В качестве члена ядра вы являетесь неотъемлемой частью команды, разрабатывающей дорожную карту. Пожалуйста, участвуйте в разработке, и продвигайте функции и исправления, которые вы хотите видеть. Также помните, что Red Hat, как компания, обязуется реализовывать определенные функции, исправления, API и т. д. для различных релизов. Red Hat, компания, и команда Ansible должны выполнить эти запланированные функции (и т. д.) и выпустить их по графику. Обязательства перед пользователями, сообществом и клиентами должны быть приоритетными. Из-за этих обязательств функция, которую вы хотите разрабатывать самостоятельно, может не войти в релиз, если она повлияет на многие другие части Ansible.

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

Наш рабочий процесс на GitHub

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

• Сделайте форк репозитория, над которым вы хотите поработать, в свой личный репозиторий.
• Работайте над конкретной веткой, в которой необходимо сделать коммит.
• Создайте запрос на включение изменений (Pull Request) обратно в репозиторий Ansible и отметьте людей, которых вы хотели бы попросить о рецензии; назначьте кого-то основным «владельцем» вашего запроса.
• Внесите необходимые изменения в код на основе предоставленных комментариев.
• Попросите кого-нибудь из Команды Ядра выполнить окончательный обзор и объединение.

Добавление к рабочему процессу для коммитеров:

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

Роли в ядре

• Ядро Коммитеры: Можно создавать запросы на включение изменений для большинства вещей, но мы должны установить лимит времени. Висящие запросы могут быть объединены по суждению этих разработчиков.
• Владельцы модулей: Владельцы модулей владеют конкретными модулями и имеют косвенный доступ к коммитам через существующие механизмы запросов на включение изменений модулей.

Общие правила

Лица с прямым доступом к коммиту в ansible/ansible наделены полномочиями, которые позволяют им выполнять широкий спектр действий — вероятно, больше, чем мы можем записать. Вместо правил рассматривайте их как общие рекомендации. От лиц с такими полномочиями ожидается применение здравого смысла.

• Не
  • Делать прямые коммиты.
  • Объединять собственные запросы на включение изменений. Кто-то другой должен иметь возможность просмотреть и одобрить объединение запроса. Если вы являетесь участником Команды Ядра, у вас есть небольшая свобода действий для очень незначительных изменений.
  • Забывать об альтернативных средах. Рассмотрите альтернативы — да, у людей бывают плохие среды, но именно они больше всего нуждаются в нас.
  • Втягивать членов своей команды вниз. Всегда обсуждайте технические преимущества, но никогда не обращайтесь к недостаткам человека (вы можете позже выпить пива с ними и назвать их идиотами, но не в IRC/GitHub и т. д.).
  • Забывать о нагрузке на обслуживание. Некоторые вещи действительно круты, но они могут не стоить того, чтобы их принудительно внедрять, если нагрузка на обслуживание слишком велика.
  • Ломать плейбуки. Всегда помните о совместимости со старыми версиями.
  • Забывать о простоте. Сложность порождает все виды проблем.
• Делать
  • Сжимать коммиты, избегать объединений, когда это возможно, использовать функцию сжатия коммитов GitHub или при необходимости использовать cherry-pick (bisect вам благодарит).
  • Быть активным. У коммитеров, которые не проявляют активности в проекте (через объединения, обработку задач, коммиты и т. д.), права будут приостановлены.
  • Учитывать обратную совместимость (это возвращается к пункту «не ломайте существующие плейбуки»).
  • Писать тесты. Запросы на включение изменений с тестами рассматриваются с большим приоритетом, чем запросы на включение изменений без тестов, для которых они должны быть добавлены. Хотя не все изменения требуют тестов, обязательно добавляйте их для исправления ошибок или изменений функциональности.
  • Обсуждать с другими коммитерами, особенно если вы в чем-то не уверены.
  • Документировать! Если ваш запрос на включение изменений представляет собой новую функцию или изменение поведения, убедитесь, что вы обновили всю связанную документацию или уведомили соответствующих людей об этом. Также полезно добавить версию ядра, с которой совместима эта документация (чтобы избежать путаницы с документацией стабильной и разработки, для обратной совместимости и т. д.).
  • Учитывать охват, иногда исправление можно обобщить.
  • Держать всё просто, тогда вещи поддаются обслуживанию, отладке и пониманию.

Ожидается, что коммитеры будут продолжать соблюдать те же руководящие принципы сообщества и внесения вклада, что и остальная часть сообщества Ansible.

Люди

Лица, которым было предложено стать частью этой группы, как правило, в течение некоторого времени существенно способствовали сообществу Ansible. Если они согласятся, их просят добавить свои имена и идентификаторы GitHub в этот файл в разделе ниже, через запрос на включение изменений. Это свидетельствует о том, что эти лица согласны действовать так, как их коллеги-коммитеры надеются, что они будут действовать.