Contributing

Contribution Flow

Take a change from proposal through pull request review
View as Markdown

This guide describes the normal contribution path after your local environment is ready. If you have not prepared a fork or configured commit sign-off, begin with Getting Started.

Decide Whether to Open an Issue

Small, focused changes can usually go directly to a pull request. Examples include typo fixes, documentation corrections, small bug fixes, and narrow configuration changes.

Open a Contribution Request before implementation when a change is large, introduces a feature, spans multiple components, or would benefit from agreement on the approach. Wait for maintainer approval before investing in a substantial implementation.

Changes that modify public APIs, communication-plane architecture, backend integration contracts, or multiple major components require a Dynamo Enhancement Proposal (DEP).

Submit and Refine the Change

1

Create a focused branch

Update your local main branch and create a descriptive branch:

$git fetch upstream
$git switch main
$git rebase upstream/main
$git switch -c yourname/fix-router-timeout

Keep one concern per branch and pull request.

2

Implement and validate

Make the smallest complete change that solves the problem. Add or update tests when behavior changes, and run the relevant checks from Code Quality.

Commit each logical change with DCO sign-off:

$git commit -s -m "fix(router): handle streaming timeout"
3

Open the pull request

Push your branch to your fork:

$git push -u origin yourname/fix-router-timeout

Open a pull request against main. Link the approved issue when one exists. Use a Conventional Commit title, such as fix(router): handle streaming timeout, and include Summary and Validation sections in the pull request description.

4

Complete automated review and CI

Respond to actionable automated review comments and fix failing checks.

For external contributions, a maintainer might need to authorize CI for the latest commit. If requested, wait for a maintainer to trigger the tests rather than repeatedly pushing unchanged commits.

You are responsible for understanding and validating all submitted code, including code produced with AI assistance.

5

Request and address review

Request review from the maintainer who approved the issue when applicable. The repository CODEOWNERS file identifies required reviewers for many paths.

Respond to review comments, push follow-up commits with DCO sign-off, and re-request review when the change is ready.

6

Keep the branch current

If the target branch advances or the pull request develops conflicts, rebase on the current upstream branch:

$git fetch upstream
$git rebase upstream/main
$git push --force-with-lease

Recheck DCO trailers after rewriting commits. See DCO and Licensing for a branch-wide check.

Issue and Review States

Common issue labels communicate the next action:

LabelMeaning
needs-triageMaintainers have not completed initial review
needs-infoThe issue needs more information from its author
approved-for-prThe proposed implementation can proceed
in-progressA contributor is working on the issue
blockedProgress depends on another change or decision

Review timing depends on the size, risk, and maintainer availability. If a pull request has had no activity for a week, leave a concise follow-up comment or contact the approving maintainer.