Відповідальні за PR
SIG Docs затверджувачі беруть участь у тижневих чергуваннях стосовно управління pull request'ами для репозиторію.
Цей розділ охоплює обовʼязки відповідальних за PR. Для отримання додаткової інформації щодо якісного рецензування, дивіться Рецензування змін.
Обовʼязки
Кожного дня під час тижневого чергування відповідальний за PR:
- Робить огляд відкритих pull request'ів на відповідність стилю та змісту.
- Почніть з найменших PRʼів (
size/XS
), і закінчіть найбільшими (size/XXL
). Огляньте стільки PRʼів, скільки зможете.
- Почніть з найменших PRʼів (
- Переконайтеся, що учасники PR підписали CLA.
- Використовуйте цей скрипт, щоб нагадати учасникам, які не підписали CLA, зробити це.
- Надання відгуків про зміни та запит технічних оглядів від членів інших SIG.
- Надання своїх пропозицій щодо запропонованих змін у PR.
- Якщо вам потрібно перевірити зміст, залиште коментар у PR і запросіть більше деталей.
- Призначте відповідну мітку(и)
sig/
. - Якщо необхідно, призначте рецензентів з блоку
reviewers:
у метаданих файлу. - Ви також можете позначити SIG для огляду, коментуючи
@kubernetes/<sig>-pr-reviews
у PR.
- Використовуйте коментар
/approve
для затвердження PR для злиття. Зливайте PR, коли він готовий.- PRʼи повинні мати коментар
/lgtm
від іншого члена перед злиттям. - Розгляньте можливість прийняття технічно правильного змісту, який не відповідає настановам зі стилю. Під час затвердження змін відкрийте новий тікет для розвʼязання питання стилю. Зазвичай такі питання стилю можна описати як гарні перші завдання.
- Використання виправлень стилю як гарних перших завдань — це хороший спосіб забезпечити наявність легших завдань для допомоги в адаптації нових учасників.
- PRʼи повинні мати коментар
- Також перевіряйте pull requestʼи до коду генератора довідкової документації та оглядайте їх (або залучайте допомогу).
- Підтримуйте відповідального за тікети у розгляді та теґуванні нових тікетів щодня. Дивіться Розгляд та категоризація тікетів для керівництва з використання метаданих SIG Docs.
Примітка:
Обовʼязки відповідального за PR не застосовуються до PRʼів локалізації (неангломовних PRʼів). Команди локалізації мають свої власні процеси та команди для огляду своїх PRʼів. Однак часто корисно переконатися, що PRʼи локалізації правильно позначені, переглянути невеликі PRʼи, що не залежать від мови (наприклад, оновлення посилань), або позначити рецензентів чи учасників у довготривалих PRʼах (тих, що відкриті понад 6 місяців і не оновлювалися більше як місяць).Корисні запити GitHub для відповідальних
Наступні запити корисні під час роботи з PRʼами. Після обробки цих запитів зазвичай залишається невеликий список PRʼів для огляду. Ці запити виключають PRʼи локалізації. Усі запити стосуються основної гілки, крім останнього.
- Без CLA, не допускається до злиття: Нагадуйте учаснику підписати CLA. Якщо і бот, і людина нагадали їм, закрийте PR і нагадайте їм, що вони можуть відкрити його після підписання CLA. Не оглядайте PRʼи, автори яких не підписали CLA!
- Потребує LGTM: Перелік PRʼів, які потребують LGTM від члена. Якщо PR потребує технічного огляду, залучайте одного з рецензентів, запропонованих ботом. Якщо зміст потребує доопрацювання, додайте пропозиції та відгуки безпосередньо.
- Має LGTM, потребує затвердження документації: Перелік PRʼів, які потребують коментаря
/approve
для злиття. - Швидкі виграші: Перелік PRʼів до основної гілки без явних блокувань. (змініть "XS" у розмірі мітки, коли будете працювати з PRʼами [XS, S, M, L, XL, XXL]).
- Не для основної гілки: Якщо PR для гілки
dev-
, це для майбутнього випуску. Призначте менеджера випуску документації використовуючи:/assign @<github-ім'я_менеджера>
. Якщо PR для старої гілки, допоможіть автору визначити кращу гілку.
Корисні команди Prow для відповідальних
# додати мітку англійської мови
/language en
# додати мітку squash до PR, якщо твм більше одного коміту
/label tide/merge-method-squash
# перейменувати PR через Prow (наприклад, робота в процесі [WIP] або кращий опис PR)
/retitle [WIP] <TITLE>
Коли закривати Pull Request'и
Огляди та затвердження є одним з інструментів для утримання нашої черги PR короткою та актуальною. Іншим інструментом є закриття.
Закрийте PRʼи, де:
Автор не підписав CLA протягом двох тижнів.
Автори можуть відкрити PR знову після підписання CLA. Це малоризикований спосіб переконатися, що нічого не зливається без підписаного CLA.
Автор не відповів на коментарі чи відгуки протягом 2 або більше тижнів.
Не бійтеся закривати pull request'и. Учасники можуть легко відкрити знову та продовжити роботу. Часто повідомлення про закриття є тим, що спонукає автора продовжити та завершити свій внесок.
Щоб закрити pull request, залиште коментар /close
у PR.
Примітка:
Ботk8s-triage-robot
позначає тікети як застарілі через 90 днів неактивності. Через 30 днів він позначає питання як "протухлі" та закриває їх. Відповідальні за PR повинні закривати їх через 14-30 днів неактивності.Програма тіньового відповідального за PR
У кінці 2021 року SIG Docs представив PR Wrangler Shadow Program. Програма була введена для допомоги новим учасникам зрозуміти процес управління PR.
Як стати тіньовим відповідальним за PR
Якщо ви зацікавлені у тому, щоби стати тіньовим відповідальним за PR, будь ласка, відвідайте сторінку Wiki PR Wrangler'ів, щоб побачити графік управління PR на цей рік та зареєструватися.
Інші можуть звернутися до Slack-каналу #sig-docs для запиту на участь у підтримці відповідальних за PR на конкретний тиждень. Не соромтеся звертатися до Бреда Топола (
@bradtopol
) або одного зі співголів/лідерів SIG Docs.Після реєстрації на підтримку відповідального за PR, представте себе відповідальному за PR у Kubernetes Slack.