Feature branches on the court case-management ART stay open for months, and merges fail just before System Demo. What quality risk should the RTE summarize?
Select an answer to reveal the explanation.
Short Explanation
Leaving case-file branches in a drawer for months is how you get a collision in the clerk's office the night before demo. Frequent integration is the quality habit that keeps surprises small. Long-lived branches just hide the crash until it is loud.
Full Explanation
Long-lived branches increase integration risk; the ART should integrate frequently so quality stays visible. When court case-management feature branches stay open for months and merges fail just before System Demo, the RTE should summarize that integration risk. Claiming longer branches are safer because judges never see incomplete screens confuses user exposure with engineering integration health. Merging only during the IP iteration so developers never interrupt coding recreates big-bang integration. Requiring a separate branch per statute so no two teams ever integrate maximizes divergence. Public-health registry interfaces stall when the real constraint is review capacity; local IDE wins at a non-bottleneck do not raise civic throughput. Exam caveat: release branching strategies can exist for controlled go-lives, but months-long feature isolation is not that strategy. Operational check: set a branch-age policy for the court ART, measure time-to-integrate, and demo integrated increments rather than branch-local builds. Time how long completed registry work waits for review and add review capacity or cadence before adding more upstream start. Hold the civic standard in facilitation notes so the next RTE inherits the same expectation for resident-facing outcomes.