17.9 Review Outcomes

Go To Top

Return to Git and Review Workflow

Each review should produce a clear outcome. The team should avoid ambiguous review states that leave developers unsure whether a change belongs in the Baseline.

Review outcomes may include:

1. Approved: the change satisfies the Baseline and may merge.
2. Approved with minor edits: the change may merge after clearly identified minor corrections.
3. Changes requested: the author must revise the change before merge.
4. Deferred: the change may be valid but does not belong in the current Phase 0 Baseline.
5. Rejected: the change conflicts with the Baseline, architecture, scope, or agreed conventions.
6. Open decision required: the change depends on a tool, architecture, Repository, or implementation decision that the team has not yet resolved.

When a review identifies an open decision, the team should record it in the Risks and Open Decisions section, an implementation decision record, or an issue tracker. The team should not merge Baseline-changing work until it resolves the open decision or explicitly accepts it.