Отслеживание задач

Мы приветствуем отчеты об ошибках, предложения по новым функциям и запросы на включение изменений через Github трекер задач Wagtail.

Задачи

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

Не используйте задачи для запросов поддержки или других вопросов («Как сделать X?» — хотя «Реализовать способ выполнения X» или «Документировать способ выполнения X» могут быть вполне допустимыми задачами). Эти вопросы следует задавать на Stack Overflow, а для обсуждений, не подходящих под формат вопросов и ответов Stack Overflow, используйте группу поддержки Wagtail в Google группах.

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

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

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

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

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

Это может потребовать немалых усилий для подтверждения наличия ошибки. В этом случае были бы особенно приветствуемы отзывы и дополнительные детали от других участников, которые могут или не могут воспроизвести ошибку.
Возможно, потребуется дополнительное обсуждение, чтобы решить, является ли предложение хорошей идеей или нет — в этом случае оно будет помечено «нужно решение по дизайну».

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

Запросы на включение изменений

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

Все участники, как основные, так и не основные, приглашаются предложить отзывы по запросу на включение изменений.
Члены основной команды приглашаются назначить себя для проверки запроса на включение изменений.

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

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

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

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

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