Retro

Вопросы к обсуждению

Это темы и вопросы для встречи, не разнарядка кому отвечать. Антон до этого момента в материалы не погружён — поэтому всё формулируем как открытые вопросы команде, а не "Антон ответит / Иван ответит". На встрече пройдёмся по этим темам совместно.

Состав внутреннего круга: Антон, Иван (frontend), Sasha Fedorenko (Contentful — App для YouTube publish date / Contentful environment), Андрей (менеджер). По части PR #842 ключевые scope-вопросы — к Саше; по части PR #837 (Contentful env master vs develop) — тоже к Саше; всё остальное — общая дискуссия.

Логика приоритетов (обновлено): наверх — то, что имеет накопительный эффект на качество (self-QA, workflow violations, технические правила). Точечный кейс «менеджер не донёс обещание» (был на 5 митах, не сложилось) — отдельный пункт ниже, не топ темы встречи.

Приоритет 1 — Self-QA / internal validation pass (накопительный эффект)

Это главная корневая причина бо́льшей части претензий клиента. 8 из 11 замечаний на PR #846 — наши self-QA промахи. Скрипт «поймали → исправили → нашли следующее» повторяется на каждом PR, цикл ревью растягивается.

Конкретные PR-кейсы где self-QA не сработал

PR #846 (header — прямо упомянут в письме Alexis "deviates from spec"):

  • Comment #4 — text-only logo в expanded mobile menu не реализован, хотя в мокапе v3 это явно. Открывался ли expanded mobile menu и сравнивался с мокапом до открытия PR?
  • Comment #3 — меню в 2 строки на 1024–1091px (регрессия от собственных изменений). Какие breakpoint'ы тестируются? RWD-режим в DevTools используется?
  • Comment #5 — dark mode WCAG-контраст. Используется ли Lighthouse / axe DevTools / contrast check?
  • Comment #9 — 4 search-issues (font, иконка, бордер, L-shape) одного блока. Side-by-side с мокапом сравнивался?
  • Comment #2 — "Info For" dropdown центрирован, но в спеке нет. Откуда взялось это центрирование?

PR #842 (frontend в YouTube schema):

  • Comment #1 — console.log('Parsed video ID:', videoId) в коде. Pre-commit hooks / lint правила, которые ловят debug-код, — есть?
  • Comment #3 — VideoObject без uploadDate (фронт-guard): почему изначально не было guard "если поле пустое — не выводить schema"?

PR #832:

  • Comment #6 — "url":"undefined/profile/fkim" на проде/preview. Реальные страницы тестируются перед открытием PR?
  • Почему ответили "no additional steps required" 24.02 — была реальная проверка?
  • Comments #7-9 — hardcoded /news/, hardcoded creditText в 2 местах. Знали про getExternalPath и Image Wrapper.credit? Делается grep по проекту перед написанием схожего кода?

PR #842 (Contentful App scope, Саша):

  • ~700 unsynced entries — думали ли про существующие данные на этапе кодинга? (Контекст: backfill потом был добавлен в App после запроса Michael.)

Общие вопросы к команде

  • Делается ли сейчас на нашей стороне internal validation pass перед отправкой PR на ревью Stevens?
    • Если да — кто, что проверяет, как фиксируется?
    • Если нет — кто должен (тимлид, менеджер, разработчик self-review, комбинация)?
  • Нужен ли обязательный self-QA checklist перед "Open PR" (см. — раздел A)? Что входит — RWD-проход через breakpoints, dark mode contrast, mockup overlay, env-vars grep, schema validation, проверка expanded states?
  • Как фиксируем прохождение acceptance criteria — в описании PR (Validation done, сверка с тикетом) без отдельного обязательного gate «internal validation» тимлида/менеджера на каждый PR? Или нужен gate?
  • Дополнение от Alexis (20:21): "a quick check against the spec prior to pushing will put us in a good place" — её предложение включить spec-sweep как обязательный шаг перед push. Закрепляем?

Приоритет 2 — PR #847, commit-after-approve

Самая серьёзная отдельная находка по workflow. В коде PR #847 есть TODO "remove and uncomment const questions when approve PR" — то есть планировалось изменить код после approve.

  • Что значил этот TODO? Действительно планировалось менять код после approval?
  • Понимание команды: approve привязан к конкретному коммиту. Если код меняется после approve — нужен повторный re-review.
  • Если задача требовала "временной" версии — почему не draft PR?
  • Договориться: никаких TODO / «when approve» в коде ветки под ревью Stevens (не готово → Draft PR); после approve — новые коммиты только после явного запроса re-review.

Приоритет 3 — Squashing / переписывание истории на расшаренных ветках

Прямо упомянут в письме Alexis 29.04 + конкретный кейс на PR #846 30.04.

Темы для обсуждения (Bitbucket / локальный git открываем вместе):

  • Branch ICUS-216-faq после merge PR #837 (24.03) — сохранилась? Удалена и пересоздана?
  • PR #837 при merge — был squash-merge через UI?
  • Между 24.03 и 24.04 — был ли git push --force в ветку?
  • Перед открытием PR #847 — был локальный rebase / squash / amend, потом push?
  • Что именно произошло на PR #846 30.04 (~2 часа до письма Michael)?
  • git reflog ICUS-216-faq — посмотреть.
  • Знаем ли правило (формулировка Alexis): "the 'golden rule' about avoiding a rebase on a shared collaboration branch"? Готовы ввести: «после первого push на remote — никаких rebase / force-push / squash локально» как командное правило?

Приоритет 4 — PR template и workflow

  • Согласны с обязательной структурой PR description (Summary / Changes / Pre-merge tasks / Migration plan / Validation done / Compare URLs)?
  • PR #842 Comment #2 — pre-merge tasks отсутствовали в description, у Michael сломался build. Знали ли, что Stevens CMS Tools / Contentful App нужно деплоить отдельно + Contentful merge develop→master? Run instructions в PR — внутри команды договаривались раньше (после двух «пинков» от клиента), но не закрепилось. Как закрепить и проверять (PR template / чек-лист / тимлид смотрит при ревью)?
  • Какое сейчас правило по squash/rebase? Формализовано ли где-то?
  • По кейсу PR #847 (commit-after-approve, TODO "when approve PR") — это разовая ошибка или знак, что у нас нет общего понимания, что approve привязан к конкретному коммиту?
  • Готовы ввести правило "если код не готов — Draft PR, никаких TODO в коде"?

Приоритет 5 — Спека и parent-тикеты

  • Есть ли сейчас правило "перед стартом сабтаска прочитать parent-задачу и приложенные документы"?
  • Спека ICUS-214 (PDF "User Stories for FAQ Schema") была приложена к Jira 11.03 в 16:34 Андреем — за 2 дня до открытия PR #837 (13.03). Открывалась ли она перед стартом?
    • Если да — почему отступили от 5 acceptance criteria (поле Accordion Purpose, Single select Standard Content/FAQ, help text)?
    • Если нет — почему не открывали parent-тикет?
  • Нужен ли Spec-read checkpoint — разработчик перед стартом пишет в Jira-комменте, что прочитал и какие acceptance criteria выписал?
  • Кто следит за фразами "to be confirmed" / "agreed before implementation begins" в спеке (Comment #11 PR #846 — data-cta)?

YouTube schema (PR #842) — разделение Саша / Иван

Важно: Contentful App для YouTube publish date — это отдельная задача Саши Федоренко. Он спроектировал и написал App, который пишет youtubeUploadDate в Contentful через YouTube API. Иван в PR #842 делал только фронт — читал поле через Delivery API и рендерил <VideoObject> JSON-LD.

Репо Contentful App найден: stevens_main_ctfapps, ветка contentful-app → master, PR #1 "Initial Contentful app import" — https://bitbucket.org/stevens_edu/stevens_main_ctfapps/pull-requests/1

  • Статус: OPEN с 2026-04-22 (~9 дней). 36 files changed, 1 commit. Reviewer Michael Forbes добавлен 2 дня назад (~29-30.04). Description: "Initial import of the Contentful app project, including source code, config, tests, and backfill tooling."
  • PR открыт автором Alex.Rudenok, не Sasha Fedorenko. Это либо тот же человек (другое написание имени / другой логин в Bitbucket), либо другой разработчик отвечает за этот App. Уточнить на встрече кто фактически вёл задачу.

Вопросы по Contentful App (scope-уровень — нужны участие Саши / Alex.Rudenok как автора PR):

  • Спека ICUS-211/212 говорит: trigger предпочтительно on Publish, fallback — on URL change. Почему выбран URL change? (Это решение в App, не во фронте.)
  • Поле youtubeUploadDate должно быть disabled для ручного редактирования в Contentful UI, но App может писать. Реализовано ли так?
  • ~700 existing entries — почему миграция не была спроектирована до открытия фронт-PR? Backfill script появился по запросу Michael (description PR App теперь упоминает "backfill tooling" — то есть его таки добавили в App, отдельно от фронта).
  • Pre-merge tasks (deploy App + Contentful field develop→master) — почему не были озвучены до открытия фронт-PR?
  • PR App OPEN с 22.04, 1 коммит, ревьюер Michael только что добавлен — синхронизация фронта (PR #842) и App (PR #1) сейчас как происходит? Они должны мержиться вместе или в каком порядке?

Вопросы по фронту PR #842:

  • Почему изначально не было guard "если youtubeUploadDate пуст — не выводить <VideoObject>"? Спека прямо требует валидной schema.
  • При написании PR description — переспросил ли у владельца scope / менеджера, что нужно для deploy этого PR (pre-merge tasks)?

Общие вопросы:

  • YouTube API key — в конфиге Contentful App; в git не попадал (проверено по PR #842 и репо App). ✓ - Был ли product-checkpoint между владельцем scope и автором фронта перед коммитом? Если нет — вводим как процесс.

Приоритет 6 — Знание codebase

  • PR #832 — не использовались getExternalPath, Image Wrapper.credit (существующие абстракции).
  • Делается ли у нас онбординг по архитектуре проекта? Есть ли карта компонентов / utilities?
  • Нужна ли практика "перед фичей просмотреть похожие места в codebase / grep по проекту"?
  • PR #837 Comment #1 — изменение content model в master Contentful вместо develop. Понимание разницы между Contentful environments (master / develop / staging) — общее?
    • Процедуру в Contentful уточнять у Саши Федоренко; на встрече — совместно зафиксировать, как поступаем дальше (единое правило, чеклист), т.к. реакция клиента накопительная, не про один комментарий.

Приоритет 7 — Невыученные уроки между PR

  • VideoObject без uploadDate — пойман в PR #842 (фронт Ивана) и PR #832 (тоже фронт Ивана, тот же класс ошибки) в один день (31.03). Между PR урок про "guard на пустое обязательное поле в schema" не закрепился. (NB: scope-владелец PR #842 — Саша, но конкретно frontend-guard "не выводить schema без uploadDate" — это уже зона Ивана.)
  • Как запоминаем уроки — что выбираем на встрече:
    • A: вести журнал в репо — черновик (таблица: дата, PR, класс ошибки, «не повторять»).
    • B: то же в Jira (коммент к parent / отдельная задача-каталог).
    • C: без отдельного файла — короткий список в + ссылка из PR template; кто обновляет — по договорённости.
    • ИИ (опционально к A–C): черновик строки для журнала или «что похожее уже ловили» из текста ревью/описания PR — с обязательной человеческой правкой перед записью; узкий пилот, без секретов (связка с вопросом Alexis про AI-tooling).
  • Кто владелец ритма (напоминание дописать строку, проверка перед стартом похожей задачи) — тимлид / менеджер / ротация / сам исполнитель перед Open PR?
  • Базовый ритм без ИИ: после merge — 1–2 строки урока; перед следующим похожим PR — перечитывание (кто первым набросал строку — не только тимлид, по договорённости).

Приоритет 8 — Размер батча и циклы ревью

  • PR #832 — 2+ месяца OPEN, 27+ коммитов. PR #846 — 11 претензий за 2 недели. Можно было разбивать?
    • Если да — почему не разбивали?
    • Если нет — какая структурная причина?
    • Исторический контекст #832: сначала одна задача (схема), потом в ту же линию — merge с master / next-seo — подтверждаем? Как в следующий раз отделяем platform/dependency work от фичи (отдельный PR, описание «merge noise», срок OPEN)?
  • Предложение Андрея (мнение, не факт; нужно согласование):
    • Если на старте видим, что задача большая — дробим заранее.
    • Если в процессе понимаем, что задача разрослась — дробим по ходу, не дожидаясь финала.
    • Зачем: чтобы не получить это как претензию от клиента в будущем.
    • Конкретно по PR #832: очевидно, что он разросся потому что разросся — не намеренно, в одну линию работ попали схема + merge с master + правки вокруг next-seo. Не виним лично; фиксируем как урок.
    • Готовы попробовать как практику?

Приоритет 9 — Языковой барьер

  • PR #846 Comment #10 (alignment) — Иван задал вопрос на ломаном английском, Michael не понял, потеряли ~3 дня на расшифровку.
  • Должен ли менеджер/тимлид перечитывать существенные комментарии разработчика к ревьюерам клиента перед публикацией?
  • Английский в комментариях ревью — нужна ли помощь с формулировками (AI-инструмент / тимлид/менеджер вычитывает крупные вопросы)?

Приоритет 10 — Контекст и история сигналов

  • Комментарий Alexis от 23.02 в PR #832: "Are there any additional steps we need to take prior to deployment?" Плюс я (Андрей) несколько раз поднимал эту тему — говорил и писал в Slack, что нас панчат за это (точные даты найти не получилось).
    • Что добавить в процесс, чтобы такие сигналы закреплялись у исполнителя PR (явное «услышал/проверил» после Slack + комментария в PR)?
    • Почему через 5 недель в PR #842 та же проблема повторилась?
  • Письмо Alexis от 29.04 — это сюрприз или ожидаемая эскалация по накопившимся замечаниям?
  • Получали ли мы раньше похожие сигналы от Tom (iX) — устно, в Slack, в звонках?

Справка (не претензия): тема внимательности к ожидаемому формату deliverable / «не на автопилоте» обсуждалась 2026-03-05 в письменном фидбеке Андрея Ивану + 1×1 (по schema coverage doc). Deliverable тогда был доведён. Если на встрече прозвучит «никто никогда не говорил» — есть нейтральная ссылка на этот разговор как факт. См. .

Приоритет 11 — Коммуникация коммитментов клиенту внутри команды (точечный кейс)

Это точечная ситуация, не системная: менеджер был на 5 митах в течение дня, не сложилось донести обещание клиенту до команды. Не выводим как первый приоритет встречи, но процесс закрепления обещаний всё равно стоит проговорить — чтобы не повторилось.

Конкретный кейс 30.04:

  • 09:50 — менеджер отправил клиенту письменное обещание: "avoid squashing commits after a branch has already been shared".
  • ~17:37 — Иван сделал squash на PR #846 (об обещании не знал).
  • 19:37 — клиент (Michael) увидел и написал второе письмо.
  • Эскалация закрыта вечером 30.04 позитивно (Alexis 20:21: "will put us in a good place").

Вопросы для команды (не для разоблачения, для процесса):

  • Какой у нас сейчас канал передачи "обещаний клиенту по процессу" внутрь команды? (Slack, Jira, устно?)
  • Предложение Андрея: когда менеджер даёт клиенту коммитмент по процессу — он в тот же день идёт в команду (короткое сообщение в общий канал + ссылка на письмо). Андрей пишет → команда подтверждает текстом ("понял, принял" / "ок, учёл" — короткое сообщение, не реакция-галочка, чтобы было видно что человек прочитал и осознанно подтвердил, а не машинально кликнул эмодзи). Согласны?
  • Эта же история шире squash'а:
    • Run instructions в PR — это не новое обещание: внутри команды мы уже договаривались об этом раньше (после того как клиент пнул дважды по этой линии). Вопрос в том, как закрепить и проверять, что инструкции реально пишутся в PR description когда для деплоя что-то нужно (Contentful merge, env var, отдельный PR в Stevens CMS Tools и т.д.). См. также Приоритет 4.
    • Header retro — в команде проговорено? Если нет, проводим, возвращаемся к Michael с findings.
    • Любые другие обещания (если вспомним) — фиксируем.

Приоритет 12 — AI-tooling (вопрос из письма Alexis)

  • Используем ли мы какие-то AI-инструменты при разработке (Copilot, Cursor, Codex)?
  • Что думаем про предложение Alexis "AI-assisted tooling has helped us during our internal experiments" — стоит ли пилотить?

Приоритет 13 — Что хотим менять (общая сводка)

  • Готовность к обязательному self-QA checklist перед каждым "Open PR" (mockup overlay, RWD-ползунок, dark mode, env-vars grep, spec sweep)?
  • Согласие с обязательной структурой PR description?
  • Согласие с правилами:
    • "no rebase / no force-push после share"
    • "no commit-after-approve"
    • "если не готов — Draft PR"?
  • Устраивает ли модель: вся пред-PR дисциплина через self-QA checklist и явное Validation done в описании PR (без отдельного обязательного просмотра тимлидом/менеджером на каждый PR)?
  • Что мешает работать качественнее? (Нечёткие задачи / спека с пробелами / нагрузка / отсутствие mockup access / др.)
  • Что бы команда сама предложила поменять в процессе?
  • Какой обратной связи не хватает?

Приоритет 14 — Ответ Stevens: тон и стратегия

  • Какой тон ответа выбираем — оборонительный, согласительный, со встречными предложениями?
  • Что нельзя признать в ответе клиенту? (Юридически или коммерчески чувствительно.)
  • Что хотим сами получить от Stevens в ответе? (Ясность по спеке, регулярные sync'и, чёткий escalation channel.)

Приоритет 15 — После встречи

  • Кто пишет первый черновик ответа Tom / Stevens?
  • К какому сроку нужно отправить ответ?
  • Распределение работ по существующим открытым PR (#832, #842, #846, #847) — как двигаем дальше?