Background
breaking change や layout/tutorial の変更では、コード差分そのものだけでなく、利用者がどう移行するか、何が前提条件か、どこで待つ必要があるか、を同時に伝える必要があります。
docs 更新だけでは、upgrade 手順や environment readiness の説明が抜けることがあります。
Problem
breaking layout/docs/tutorial 変更において、upgrade note、migration impact、environment readiness が PR ごとに安定して揃う運用になっていない可能性があります。
その結果、後続 cleanup、レビュー時の認識ずれ、利用者の試行錯誤が発生しやすくなります。
Proposal
breaking layout/docs/tutorial 系の PR では、以下の項目を PR template または checklist で必須化したいです。
- Upgrade note
- Migration impact
- Environment readiness
- Starter / scaffold expectation
重要なのは文量を増やすことではなく、利用者が移行や再現に必要な前提を落とさず読める状態を標準化することです。
Expected benefit
- breaking change の説明漏れを減らせる
- reviewer が受け入れ条件を確認しやすくなる
- 利用者の移行時の迷いを減らせる
- 後続 cleanup PR や補足説明の必要性を減らせる
Definition of done
- breaking layout/docs/tutorial PR に所定の note 欄が追加される
- 当該欄が空欄のままでは merge しない運用が定義される
- release note や migration guide への反映方針が整理される
- 最低限どのケースで note が必要かが明文化される
Background
breaking change や layout/tutorial の変更では、コード差分そのものだけでなく、利用者がどう移行するか、何が前提条件か、どこで待つ必要があるか、を同時に伝える必要があります。
docs 更新だけでは、upgrade 手順や environment readiness の説明が抜けることがあります。
Problem
breaking layout/docs/tutorial 変更において、upgrade note、migration impact、environment readiness が PR ごとに安定して揃う運用になっていない可能性があります。
その結果、後続 cleanup、レビュー時の認識ずれ、利用者の試行錯誤が発生しやすくなります。
Proposal
breaking layout/docs/tutorial 系の PR では、以下の項目を PR template または checklist で必須化したいです。
重要なのは文量を増やすことではなく、利用者が移行や再現に必要な前提を落とさず読める状態を標準化することです。
Expected benefit
Definition of done