Рекомендации по триажу issue
Назначение
Ускорить управление issue.
Issue проекта etcd перечислены на странице https://github.com/etcd-io/etcd/issues
и классифицируются с помощью меток. Например, issue, признанный ошибкой,
в итоге получает метку area/bug . Новые issue сначала не имеют меток, но обычно
сопровождающие и активные участники etcd добавляют их по результатам анализа.
Подробный список меток находится на странице
https://github.com/kubernetes/kubernetes/labels
Для удобства ниже приведено несколько готовых поисковых запросов:
Область применения
Эти рекомендации служат основным документом по триажу поступающих issue в etcd. Помогать с issue и PR могут все желающие, однако описанные здесь работа и обязанности рассчитаны прежде всего на сопровождающих и активных участников etcd.
Проверка, является ли issue ошибкой
Убедитесь, что issue действительно описывает ошибку. Если это не так, добавьте комментарий с результатами анализа и закройте очевидный issue. Для нетривиального случая дождитесь ответа автора и возможных возражений. Если автор не отвечает 30 дней, закройте issue. Если проблему не удаётся воспроизвести или требуются дополнительные сведения, оставьте автору комментарий.
Неактивные issue
Issue с недостаточным объёмом сведений следует закрыть, если автор не предоставляет запрошенную информацию в течение 60 дней.
Дублирующие issue
Если issue дублирует существующий, добавьте комментарий со ссылкой на исходный issue и закройте дубликат.
Issue, не относящиеся к etcd
Иногда сообщают о проблемах, которые на самом деле относятся к другим проектам, используемым etcd, например к grpc или golang. Попросите автора открыть issue в соответствующем проекте. Закройте исходный issue, если сопровождающий и автор не считают необходимым оставить его открытым для отслеживания.
Проверка важных меток
Убедитесь, что issue помечен метками соответствующих областей, назначены подходящие исполнители и указан этап. Добавьте отсутствующие метки. Если прав для этого недостаточно или правильную метку выбрать не удаётся, при необходимости обратитесь к сопровождающим.
При необходимости напомните владельцу issue
Если разработчик владеет issue, но за 30 дней не создал PR, свяжитесь с ним и попросите подготовить PR либо освободить issue для другого исполнителя.