diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml index a49f609ab..b44b64632 100644 --- a/.github/ISSUE_TEMPLATE/config.yml +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -1,7 +1,7 @@ blank_issues_enabled: false contact_links: - name: Question or discussion - url: https://github.com/NVIDIA/switchyard/discussions + url: https://github.com/NVIDIA-NeMo/Switchyard/discussions about: For usage questions and design discussion, please open a Discussion instead of an Issue. - name: Security vulnerability url: https://www.nvidia.com/en-us/security/ diff --git a/.secrets.baseline b/.secrets.baseline index fc265534d..c5156f989 100644 --- a/.secrets.baseline +++ b/.secrets.baseline @@ -234,7 +234,7 @@ "filename": "CONTRIBUTING.md", "hashed_secret": "ec3810e10fb78db55ce38b9c18d1c3eb1db739e0", "is_verified": false, - "line_number": 131 + "line_number": 162 } ], "DEVELOPMENT.md": [ @@ -1189,5 +1189,5 @@ } ] }, - "generated_at": "2026-07-08T09:06:49Z" + "generated_at": "2026-07-09T16:39:36Z" } diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 82087834b..8213bed5a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,6 +2,36 @@ Thank you for your interest in contributing! This document outlines the development workflow, testing practices, and code standards. +## External Contributions + +We welcome contributions of all sizes, from typo fixes to new features. The short version: + +1. [Fork the repository](https://github.com/NVIDIA-NeMo/Switchyard/fork) and clone your fork: + + ```bash + git clone https://github.com/YOUR-USERNAME/Switchyard.git + cd Switchyard + git remote add upstream https://github.com/NVIDIA-NeMo/Switchyard.git + ``` + +2. Pick the right process for the size of your change: + - **Small changes** (typos, docs, focused bug fixes under ~100 lines): open a PR directly, no issue needed. + - **Larger changes** (new features, refactors, anything 100+ lines): [open an issue](https://github.com/NVIDIA-NeMo/Switchyard/issues/new/choose) first so maintainers can confirm the direction before you invest time. + +3. Create a branch, make your change, and run the checks in [Code standards](#2-code-standards). + +4. Commit with a DCO sign-off (see [Signing Your Work](#signing-your-work)): + + ```bash + git commit -s -m "fix: description of the change" + ``` + +5. Push to your fork and open a PR against `main`, linking any related issues (e.g. "Closes #42"). + +Review is requested automatically from the core team via [CODEOWNERS](.github/CODEOWNERS), so there is no need to pick reviewers. Keep each PR focused on one concern, include tests for behavior changes, and respond to feedback with follow-up commits rather than force-pushes. + +Using AI tools to write code is fine, but you must understand and be able to explain every change in your PR. + ## Setup See [Development](DEVELOPMENT.md) for full setup instructions. @@ -57,6 +87,9 @@ Commit messages must follow [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/). This is enforced locally by the `commit-msg` hook and in GitHub Actions. +Every commit must also carry a DCO sign-off (`git commit -s`), enforced by the +required DCO check on every PR. See [Signing Your Work](#signing-your-work). + - ✓ `fix: handle async context cleanup in ProxyContext` - ✓ `feat: add stage-router routing backend` - ✗ `Fixed stuff` / `Updated code` @@ -110,10 +143,8 @@ feat(api)!: remove legacy route option Keep the PR title conventional too, because GitHub can use the PR title for the squash-merge commit. -Maintainers should mark these GitHub status checks as required on `main`: - -- `Commitlint / Commit messages` -- `PR Title / Validate PR title` +The `CI Success` and `DCO` status checks are required on `main`; the other +workflows (commitlint, PR title) run on every PR but are advisory. ## Testing