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

Проблемы

Проблема должна всегда соответствовать конкретному действию с хорошо определенным состоянием завершения: исправление ошибки, добавление новой функции, обновление документации или очистка кода. Неопределенные проблемы, где конечный результат не сразу понятен («найти способ перевода» или «Добавить больше функций к полям 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 ошибок и прокомментировать, является ли это действительной ошибкой или нет, с дополнительными шагами для воспроизведения, если необходимо.

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

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

• invalid (закрыто): эта проблема не определяет конкретное действие, которое нужно выполнить, или это действие не то, что мы хотим выполнить. Например — сообщение об ошибке для чего-то, что работает как задумывалось, или запрос на функцию для чего-то, что активно вредит.
• real-soon-now: ни у кого из членов основной команды нет ресурсов, выделенных для работы над этим прямо сейчас, но мы знаем, что это больная точка, и она будет иметь приоритет, как только мы снова получим возможность выбрать что-то новое для работы. На практике такой свободный выбор происходит не очень часто — на то, над чем мы работаем изо дня в день, влияет много факторов — поэтому, если вам нужна эта функция или исправление, мы рекомендуем вам поработать над этим и внести запрос на добавление, а не ждать, пока основная команда доберется до этого!
• Конкретный номер версии (например, 1.6): проблема достаточно важна, чтобы ее нужно было исправить в этой версии. Есть выделенные ресурсы и/или планы по работе над проблемой в данной версии.
• Нет этапа выпуска: проблема принимается как действительная после удаления метки status:Unconfirmed, (когда она подтверждена как сообщение об ошибке для действительной ошибки или полезный запрос на новую функцию), но не считается приоритетной для работы (по мнению основной команды). Например — ошибка, которая является только косметической, или функция, которая была бы довольно интересной, но не совсем необходимой. Ресурсы на нее не выделены — чувствуйте себя свободными принять ее!

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

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

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

Запросы на добавление

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

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

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

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

Члены основной команды, работающие над Wagtail, должны проходить ту же процедуру со своей собственной веткой проекта.

График выпуска

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

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