17.4 Pull Request Expectations

Go To Top

Return to Git and Review Workflow

Pull requests should give reviewers enough information to understand what changed, why it changed, and how the change affects the Phase 0 Baseline.

A pull request should identify:

1. Purpose of the change.
2. Affected handbook sections, Repository directories, Nodes, Topics, scripts, Configuration files, generated Artifacts, containers, tests, or checklist instances.
3. Related implementation decision records, risks, open issues, or acceptance criteria.
4. Validation performed.
5. Evidence added or updated.
6. Known limitations or deferred work.
7. Compatibility impact, especially for IDL, generated types, Topics, QoS, Node interfaces, scripts, and containers.
8. Required reviewer focus.

A pull request that changes IDL definitions should identify the affected Topics, generated Artifacts, Node implementations, tests, and compatibility assumptions. A pull request that changes scripts should identify the expected working directory, inputs, outputs, exit codes, and validation results. A pull request that changes containers should identify build inputs, runtime Configuration, networking assumptions, and logs.

The team should avoid accepting pull requests that “work locally” but do not document their assumptions, update affected Artifacts, or provide enough Evidence for review.