本文由 AI 分析生成
Summary
GitLab Application Security team’s milestone planning process, including capacity expectations (3-4 Large issues per IC per milestone), required label taxonomy (AppSecWorkflow, AppSecPriority, AppSecWeight, AppSecWorkType), weekly status update format, and end-of-milestone retrospective procedures.
GitLab AppSec 團隊的 Milestone 規劃流程，涵蓋容量評估、標籤要求、每週狀態更新格式、以及里程碑結束時的回顧與 missed label 處理。
Key Points
- Capacity expectation: ICs take 3-4
AppSecWeight::Largeissues per milestone (adjusted for rotations and PTO) - Required labels on every AppSec issue:
Security::Division,Department::Product Security,Application Security Team, plus workflow/priority/weight/worktype labels - Priority tiers: 1 = must finish this milestone, 2 = starts after P1 done (becomes P1 next cycle), 3 = evaluated each planning session
- Missed milestone: apply
missed:X.Ylabel, roll to next milestone, reassess weight and priority - Unplanned work: document why it’s urgent, apply
Unplannedlabel, inform stakeholders of displaced work - Weekly update format: What’s happened / What’s next / Blockers / Overall Status (🟢/🟡/🔴)
- Issue health status in GitLab UI must match the weekly update confidence level
Insights
- The explicit capacity formula (3-4 Large issues) is notable — most teams leave capacity planning implicit. Externalizing this as a label-based metric (AppSecWeight) enables velocity tracking and retrospective analysis.
- The
missed:X.Ylabel pattern preserves historical evidence of planning misses without losing the issue — better than silently rolling milestones.
Connections
- Milestones project management guidelines — the general milestone system this implements
- Labels project management guidelines — label design principles behind AppSec’s taxonomy
Raw Excerpt
“On average it’s expected that ICs have 3 to 4 issues that are estimated to be classified as AppSecWeight::Large from our Effort Classification table depending on the rotations and planned PTO.”