GitHub Projects: дошка проєкту від issue до релізу

Майлстоун показує, скільки елементів закрито. Але на друге запитання CEO він не відповість: «Хто що робить цього тижня і чи встигаємо ми?» Таблиця поруч із GitHub відповіла б, але днів зо два, поки не застаріє.

GitHub Projects — простір для планування на GitHub поверх issues і pull requests. Від таблиці його відрізняють три речі:

• Проєкт належить організації або людині, а не одному репозиторію, тож може містити issues і pull requests із кількох репозиторіїв одночасно.
• Кожен елемент — справжнє issue чи pull request, а не копія. Коли #159 закрили, кожен проєкт, де воно було, одразу це показав.
• З репозиторію нічого не переїжджає. Issues лишаються на своїх місцях, а проєкт лише впорядковує їх.

Тож у Котокормі створюють проєкт «Loyalty launch» в організації catchow і додають туди елементи майлстоуна. Відтепер план і робота не можуть розійтися, бо це ті самі об'єкти, на які дивляться з двох місць.

Проєкт наповнюється трьома способами.

• Наявні issues і pull requests. Встав посилання або набери # у проєкті й знайди елемент за номером чи назвою. Елементи можуть бути з будь-якого репозиторію, який бачить власник проєкту.
• Чернеткові елементи. Швидка нотатка, яка живе лише в проєкті: назва, опис і ті самі поля, що й у будь-якої картки, тож вона може стояти в колонці й мати пріоритет. Номера й репозиторію в неї немає, і в списку issues репозиторію її не видно. Коли ідея дозріла, вибери Convert to issue, вкажи репозиторій, і вона стане справжнім issue з номером.
• Воркфлоу можуть додавати елементи за тебе, наприклад кожне нове issue з певною міткою. До них ми дійдемо за хвилину.

Чернеткові елементи пасують для сирих думок на плануванні: «Ask support for a loyalty FAQ». Тримати в них справжню роботу не варто, бо поза проєктом їх ніхто не знайде й не зможе на них послатися. А видалення issue з проєкту лише знімає картку з плану; саме issue лишається відкритим у репозиторії.

У проєкту є подання (views), збережені як вкладки вгорі. Станом на 2026 рік кожне подання використовує один із трьох макетів.

• Table — це таблиця: рядок на кожен елемент, поля як колонки, редагування просто в клітинці. Найшвидший спосіб за один присід виставити пріоритет двадцятьом новим issues.
• Board — канбан-дошка: картки в колонках, одна колонка на кожне значення поля, зазвичай Status. Перетягнеш картку в іншу колонку — зміниться значення поля. Тут живуть розробники: In progress, коли почали, In review, коли pull request готовий.
• Roadmap розкладає елементи на часовій шкалі за полем дати чи ітерації, з позначками на кшталт дедлайну майлстоуна. Відповідає на запитання «коли?», тож це природне подання для CEO.

Фільтри, сортування й групування — не окремий макет: вони є в кожному поданні й зберігаються разом із ним. Фільтр на кшталт label:bug is:open працює і в таблиці, і на дошці, і в roadmap.

Усі подання показують ті самі елементи. Зміни поле в одному, і решта покажуть цю зміну.

Колонки дошки беруться з полів. Status вбудований і спершу має значення Todo, In Progress і Done. Додай четверте значення, In review, між двома останніми, і на дошці одразу з'явиться четверта колонка.

Issues приносять у проєкт власні поля: виконавців, мітки, майлстоун, пов'язані pull requests і навіть прогрес sub-issues на кшталт «1 з 4». Це поля самого issue, тож вони однакові в кожному проєкті й на сторінці issue.

Крім того, проєкт може мати власні поля (custom fields). Для запуску лояльності досить трьох:

• Priority — вибір одного значення з P1, P2 і P3;
• Target date — дата, з якої будується макет roadmap;
• Iteration — тижневі проміжки з понеділка до п'ятниці, тож «що в нас цього тижня?» стає фільтром, а не нарадою.

Власні поля належать проєкту, а не issue. #163 може мати P1 у «Loyalty launch» і не мати пріоритету в іншому проєкті. На сторінці самого issue вони показуються в розділі Projects бокової панелі, окремим блоком для кожного проєкту.

До середи на дошці «Loyalty launch» чотири колонки справжньої роботи. #164, перемикач запуску, чекає в Todo. Батьківське #147 стоїть у In progress із позначкою «закрито 1 з 4» sub-issues, поруч із #163, списанням балів під час оформлення (Daniel, P1, ціль 5 листопада), і чернеткою сторінки програми від контент-маркетологині Emma, #157. #162, баланс, у колонці In review з пов'язаним pull request #166. #159 у Done, його закрив #165.

Читай дошку справа наліво: що завершено, що чекає на рев'юера, що будують, що ще не почали. Праві колонки найближчі до клієнтів, тож цього тижня вони найважливіші.

Колонка рев'ю — місце, де продакт може допомогти найбільше. Робота в ній уже зроблена й чекає на людей: на схвалення, на відповідь на коментар, на мердж. Нагадування потрібному рев'юеру часто зрушує картку далі, ніж будь-яка нова робота.

Читаючи, розрізняй дві речі. Priority каже, що найважливіше, а не що найближче до завершення. А колонка батьківського issue мало що каже про прогрес; справжню картину показують його sub-issues.

Ніхто не хоче щоп'ятниці бігати за людьми, щоб вони перетягували картки. Станом на 2026 рік у проєкту є вбудовані воркфлоу в меню Workflows, і частину дошки вони підтримують актуальною самі.

У кожному новому проєкті ввімкнено два:

• Item closed: коли issue чи pull request закривають, його Status стає Done.
• Pull request merged: коли pull request змерджено, його Status стає Done.

Daniel вмикає ще два. Item added to project ставить Status = Todo, а Auto-add to project додає кожне нове issue з catchow/website з міткою loyalty. Тепер нове issue лояльності саме опиняється в Todo, а pull request із Fixes #162 під час мерджу закриває #162, і картка переходить у Done. Середні колонки люди й далі рухають вручну або скриптом GitHub Actions.

Ось чому ключове слово закриття тепер важить удвічі більше. Якщо в описі написано Part of #162, #162 лишиться відкритим, його картка застрягне в In review, і дошка брехатиме, поки хтось не помітить. А публікація релізу взагалі не рухає карток.

У четвер команда публікує v1.5.0: #156, #160, #165 і #166 від часу v1.4.1. Дві картки лояльності лежать у Done, нотатки до релізу перелічують їхні pull requests, а клієнти досі нічого не бачать.

На цій дошці Done означає змерджено або закрито. У Котокормі це ще й «викладено за кілька хвилин». Але вся програма схована за фіча-флагом loyalty-points, увімкненим лише для працівників, а флага дошка не бачить.

На кожне запитання є своє джерело правди:

• Дошка проєкту: робота, відповідальні і чи вкладаємося в графік.
• Сторінка pull request: рев'ю, схвалення й перевірки.
• Deployments → production: який коміт зараз працює на живому сайті.
• Сторінка релізу: у якій версії зміна з'явилася вперше.
• Панель флагів: чим клієнти справді можуть користуватися.

Тож коли питають «це вже працює?», не зачитуй дошку. Подивись production у Deployments і флаг, і скажи, яку з двох відповідей ти даєш.

CEO відкриває дошку й пише: «2 з 4 sub-issues у Done, тобто ми наполовину запустилися?» Для дошки, створеної не для нього, це чесне прочитання, і воно хибне: обидві готові частини сховані за флагом, тож у клієнтів поки нічого немає.

Команди розв'язують це двома способами. Одні додають колонку Released і переносять туди картки в день релізу. Котокорм лишає за Done значення «змерджено або закрито» й робить запуск окремою карткою: #164 «Switch on loyalty points for all customers», відповідальна Sofia, чекає в Todo до 10 листопада. Так момент, коли клієнти отримують фічу, видно на дошці, з відповідальною і датою.

Добра відповідь CEO у двох-трьох реченнях розділяє три речі:

• що збудовано: виправлення бага й баланс змерджено, і вони працюють для працівників;
• що бачать клієнти: поки нічого, бо флаг увімкнено лише для працівників;
• що далі: списання під час оформлення (ціль 5 листопада), потім увімкнення 10 листопада.

Згадка про флаг ще й заспокоює: запуск — це перемикач, яким керує команда, а не лотерея.

Простежмо одну частину програми лояльності, #163 «Spend points at checkout», на всьому шляху:

1. Відкривають issue #163 з міткою loyalty.
2. Воркфлоу auto-add додає його на дошку в Todo.
3. Daniel переносить картку в In progress і починає pull request #167 з Fixes #163.
4. Картка переходить у In review; Oscar і Sofia переглядають #167.
5. #167 змерджено й викладено; #163 закривається, і воркфлоу переносить картку в Done.
6. Реліз наступного четверга, v1.6.0, згадує #167 у нотатках.
7. 10 листопада флаг loyalty-points вмикають для всіх клієнтів.

Лише крок 7 змінює те, що можуть робити клієнти. Усе до нього — робота команди, за якою стежить дошка.

Цей самий поділ задає й щотижневе оновлення для CEO: що змінилося за тиждень, що під ризиком і що буде далі, його словами, а не мовою дошки. Дай йому власне подання — Roadmap, відфільтрований за issues лояльності, за цільовими датами й із позначкою майлстоуна, — і не показуй чернеток і деталей по колонках.