Отслеживание проблем

Проблемы

Проблема всегда должна соответствовать определенному действию с четко определенным состоянием завершения: исправление ошибки, добавление новой функции, обновление документации или очистка кода. Проблемы с открытым концом, где конечный результат не сразу понятен («придумать способ выполнения переводов» или «Добавить больше функций в поля rich text») лучше подходят для Github discussions, чтобы можно было получить обратную связь о четком способе продвижения проблемы и определить, когда она завершена, создав отдельные проблемы из обсуждения.

Не используйте проблемы для запросов поддержки или других вопросов («Как сделать X?» — хотя «Реализовать способ выполнения X» или «Документировать, как выполнить X» вполне могут быть допустимыми проблемами). Эти вопросы следует задавать на Stack Overflow. Для обсуждений, которые не подходят под формат вопросов и ответов Stack Overflow, см. другие варианты поддержки сообщества Wagtail [https://github.com/wagtail/wagtail#community-support].

Как только билет открыт — желательно в течение одного дня — член основной команды даст ему первоначальную классификацию, закрыв его из-за некорректности или обновив его соответствующими метками. Когда открывается ошибка, она автоматически получает метки type:Bug и status:Unconfirmed, после подтверждения ошибка может потерять статус «неподтвержденная». Член команды также потенциально добавит этап выпуска, чтобы помочь определить приоритет этой проблемы. Все желающие могут помочь Wagtail в воспроизведении status:Unconfirmed ошибок и прокомментировать, является ли это действительной ошибкой или нет, с дополнительными шагами для воспроизведения, если необходимо.

Не расстраивайтесь, если вы считаете, что ваш билет получил более низкий приоритет, чем заслуживает — это решение не является окончательным. Мы рассмотрим все отзывы и переназначим или откроем билеты, где это уместно. (С другой стороны, это означает, что член основной команды, выполняющий классификацию, должен чувствовать себя свободно, принимая односторонние решения — нет необходимости сначала искать консенсус. Если он совершит неправильную оценку, это всегда можно исправить позже.)

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

• недействительный (закрытый): эта проблема не определяет конкретного действия, которое необходимо выполнить, или действие не является тем, которое мы хотим выполнить. Например — отчет об ошибке для чего-то, что работает по задуманному принципу, или предложение функции для чего-то, что активно вредит.
• очень скоро: ни у кого из членов основной команды нет ресурсов, выделенных для работы над этим прямо сейчас, но мы знаем, что это больная точка, и она будет иметь приоритет, когда мы в следующий раз сможем выбрать что-то новое для работы. На практике такой свободный выбор происходит не очень часто — на то, над чем мы работаем каждый день, оказывает много давления — поэтому, если вам нужна эта функция или исправление, мы рекомендуем вам над этим поработать и внести pull-запрос, а не ждать, пока основная команда не доберется до этого!
• Конкретный номер версии (например, 1.6): проблема достаточно важна, чтобы ее нужно было исправить в этой версии. Есть выделенные ресурсы и/или планы работы над проблемой в данной версии.
• Без этапа выпуска: проблема считается действительной после удаления метки git commit --fixup (т.е. это отчет об ошибке для реальной ошибки или полезное предложение функции), но не считается приоритетной для работы (по мнению основной команды). Например — ошибка, которая является только косметической, или функция, которая была бы интересной, но не является действительно необходимой. Нет выделенных ресурсов — не стесняйтесь взяться за это!

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

• Для подтверждения наличия ошибки может потребоваться значительная работа. В этом случае особенно приветствуются отзывы и дополнительные детали от других участников, которые могут или не могут воспроизвести ошибку.
• Для принятия решения о том, является ли предложение хорошей идеей или нет, может потребоваться дальнейшее обсуждение — в этом случае будет установлена метка “необходимое решение по дизайну”.

Мы будем стремиться к тому, чтобы проблемы не оставались в этом состоянии длительное время. Проблемы и PR, помеченные как «необходимое решение по дизайну», будут регулярно пересматриваться и обсуждаться, по крайней мере, с двумя ключевыми участниками — мы стремимся пересматривать каждый билет, по крайней мере, один раз за цикл выпуска (= 6 недель), в рамках еженедельных встреч основной команды.

Pull-запросы

Как и в случае с проблемами, основная команда будет классифицировать pull-запросы сразу после их открытия, обычно в течение одного дня. Если изменение недействительное или особенно спорное (в этом случае оно будет закрыто или помечено как «необходимое решение по дизайну»). Обычно оно будет классифицировано по следующей применимой версии — следующему младшему релизу для новых функций или следующему релизу исправления для исправлений ошибок — и помечено как «Требуется проверка».

• Все участники, основные и не основные, приглашаются для предоставления отзывов о pull-запросе.
• Члены основной команды приглашаются назначить себя для проверки pull-запроса.
• Более подробные сведения о том, как обрабатывать Pull-запросы, можно найти на странице wiki по обработке pull-запросов PR triage wiki page.

Впоследствии (желательно в течение недели или двух, но возможно дольше для больших отправлений) член основной команды сольет его, если он готов для слияния, или пометит его как требующий дальнейшей работы («нужно исправить» / «нужны тесты» / «нужны документы»). Pull-запросы, которые требуют дальнейшей работы, обрабатываются и приоритизируются так же, как и проблемы — любой желающий может взять один из них из очереди, независимо от того, был ли он первоначальным автором коммита.

Перебазирование/сжатие pull-запросов приветствуется, но не является обязательным. При этом не следует сжимать коммиты, которые нуждаются в проверке, в предыдущие, и необходимо сохранить последовательность изменений. Для исправления ошибок в предыдущих коммитах используйте git commit --fixup, чтобы окончательное слияние можно было выполнить с git rebase -i --autosquash.

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

График релизов

Мы стремимся выпускать новую версию каждые 2 месяца. Чтобы придерживаться этого графика, мы будем «поднимать» проблемы и pull-запросы до будущей версии, если это необходимо, а не позволять им откладывать текущую. По этой причине пометка проблемы под конкретным этапом выпуска не должна рассматриваться как гарантия того, что функция фактически будет выпущена в этом релизе.

• Полный список дат см. на странице wiki Release Schedule wiki page.
• Общие рекомендации по планированию проекта см. на странице wiki Roadmap wiki page.