Личный программный проект редко страдает от недостатка ярлыков. Чаще непонятно другое: что исправлять первым, чем ошибка отличается от пожелания и когда задача считается законченной. Обновление GitHub от 11 ноября делает инструменты планирования доступнее для индивидуальных разработчиков, но полезность этих инструментов по-прежнему зависит от договорённостей, а не от количества заполненных полей.

Что теперь доступно личным аккаунтам

GitHub объявил общую доступность типов и полей issues в репозиториях, принадлежащих личным аккаунтам. В настройках аккаунта, в разделе Planning, можно изменять стандартные типы Bug, Task и Feature и создавать собственные — до 25 типов. Для полей действует отдельный предел до 25; поддерживаются текст, число, дата, одиночный и множественный выбор.

Среди начальных полей названы Priority, Effort, Start date и Target date. Тип и значения можно задавать при создании issue или в существующей задаче; предусмотрено использование в проектах. Это расширение возможностей личных репозиториев, а не требование немедленно перестроить весь рабочий процесс.

Сначала решение, затем поле

Мы бы начинали настройку с вопроса: какое решение изменится, если заполнить этот атрибут? Если ответ неясен, поле пока не нужно. Например, собственная оценка срочности полезна лишь тогда, когда понятно, какие задачи действительно прерывают текущую работу. Иначе каждая новая запись постепенно становится «самой важной», а аккуратная доска перестаёт помогать выбору.

Для небольшого проекта разумнее договориться о нескольких различиях. Ошибка описывает наблюдаемое отклонение, пожелание — желаемое изменение поведения, техническая задача — необходимую работу. Это наш пример классификации, а не обязательные определения GitHub. Важно, чтобы автор проекта мог одинаково объяснить их себе сегодня и участнику обсуждения через месяц.

Срок не равен обещанию

Дата в карточке легко выглядит убедительнее, чем основания для неё. Поэтому мы предлагаем заранее определить, что означает выбранный срок: личный ориентир, момент повторного просмотра или согласованную поставку результата. Эти смыслы лучше не смешивать. Для открытого проекта особенно полезно прямо писать, когда срок предварительный, а не оставлять читателю догадываться по заполненной ячейке.

Оценка усилий тоже нуждается в контексте. Вместо внешне точных чисел можно начать с простой внутренней шкалы и возвращаться к ней после завершения работы. Ценность такого подхода — в обсуждении неизвестности, а не в имитации точного прогноза.

Проверка на пользу через несколько задач

Мы рекомендуем не переносить весь архив за один вечер. Выберите несколько живых задач и попробуйте новую схему на них. Стало ли легче объяснить приоритет? Исчезло ли повторение одной и той же информации в названии, метке и комментарии? Появились ли поля, которые никто не использует? Ответы покажут, что оставить, а что упростить.

Наша оценка обновления положительная именно из-за свободы выбора: личному проекту доступна более структурированная работа без необходимости изображать большую организацию. Но хороший процесс остаётся маленьким и понятным. Лучше три договорённости, которые действительно помогают принимать решения, чем двадцать пять типов, смысл которых приходится каждый раз восстанавливать по памяти.

Обложка — оригинальная концептуальная иллюстрация планирования задач, не снимок интерфейса GitHub.