1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/linuxsuren-open-source-best-practice

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
review.md 5.2 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 07.03.2025 23:59 4ef9e6d
  • Основной принцип открытого исходного кода — прозрачность и откровенность.
    • Даже если проверка кода не проводится, как можно говорить об открытом исходном коде? Откройте не только результат, но и процесс.
    • Проверка не ограничивается контролем качества; любой может стать проверяющим и получить выгоду от этого процесса.
  • Цикл жизни
    • Pull Request (PR) не подходят для ситуаций с экстренной необходимостью слияния.
    • После отправки PR автор должен самостоятельно проверить его; если найдены ошибки, отметьте PR как "в работе".
      • Название PR, который ещё не готов к проверке, можно пометить префиксом WIP:.
      • Если вы не уверены в некоторых частях кода (документации), вы можете высказаться в виде комментария.
    • В течение 2–7 дней следует завершить проверку и объединение.
  • Этикет
    • Никто не обязан проверять ваш PR, включая поддерживаемых лиц.
    • Каждый проверяющий помогает вам с объединением PR; выразите им благодарность.
    • В период лучших проверок не спешите с этим процессом.
    • Если действительно требуется помощь в проверке, предоставьте объяснение и приоритетное упоминание команды, а затем конкретного человека, и извинитесь за беспокойство.
  • Ясность ваших замечаний
    • Избегайте двусмысленных комментариев; автор должен принимать решения на основе вашего совета. * Для неопределенных проблем вы можете указать: "Мне кажется, что здесь могут возникнуть проблемы; предложите метод исправления и причины, и укажите, что этот комментарий не препятствует объединению PR."
    • Для очевидных проблем предоставьте информацию или данные, подтверждающие ваши взгляды; если есть официальные источники, укажите ссылки.
      • Например: неправильные комментарии в PR, предоставьте ссылку на официальную документацию сообщества.
  • Проверяющие
    • Любой может стать проверяющим, если он считает, что есть проблемы или возможности для улучшения; предоставьте доказательства своих заявлений и ссылки на источники.
    • Приоритетное обращение к команде поможет получить больше помощи.
    • Обычно каждый файл совершенствуется несколькими участниками; рассмотрите возможность привлечения последнего участника, который работал над данным файлом.
    • Если вы решаете проблему или добавляете новую функциональность, созданную другим участником, попробуйте обратиться к нему за помощь.
  • Автоматизация процесса
    • Используйте автоматизированные инструменты, такие как Lighthouse, для управления процессом проверки.
    • Прежде чем объединять изменения, следует максимально использовать автоматизированные тесты (юнит-тесты, e2e-тесты, нагрузочные тесты и т. д.)
  • Избегайте вмешательства человека в процесс автоматизации* Если проверка завершена, но требуется ещё некоторое ручное подтверждение, чтобы избежать раннего автоматического слияния, можно воспользоваться командой комментария для блокировки.
    • Например: с помощью комментария /hold можно заблокировать аккаунт бота от автоматического слияния.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/linuxsuren-open-source-best-practice.git
git@api.gitlife.ru:oschina-mirror/linuxsuren-open-source-best-practice.git
oschina-mirror
linuxsuren-open-source-best-practice
linuxsuren-open-source-best-practice
master