docs: Adapt Relay's contributor guide

[dagardner-nv]

• I confirm this contribution is my own work, or I have the right to submit it under this project's license.
• I searched existing issues and open pull requests, and this does not duplicate existing work.

Summary by CodeRabbit

• Documentation
  • Added a contributor guide for NeMo Fabric with setup, build, and test command instructions.
  • Documented release tag naming rules, coding standards for Rust/Python, commit message conventions, and pull request expectations.
  • Included contribution checklists and guidance on required license headers and DCO sign-off.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 8cfeba09-018f-42ef-909a-450ff3b767d6

📥 Commits

Reviewing files that changed from the base of the PR and between 6e71b48 and 27fae2d.

📒 Files selected for processing (1)

• CONTRIBUTING.md

📜 Recent review details

🧰 Additional context used

📓 Path-based instructions (5)

**/*.{md,mdx}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)

**/*.{md,mdx}: Spell NVIDIA in all caps; do not use Nvidia, nvidia, nVidia, nVIDIA, or NV.
Use an NVIDIA before a noun because NVIDIA starts with an "en" sound.
Do not add a registered trademark symbol after NVIDIA when referring to the company.
Use trademark symbols with product names only when the document type or legal guidance requires them.
Verify official capitalization, spacing, and hyphenation for NVIDIA product names.
Precede NVIDIA product names with NVIDIA on first mention when it is natural and accurate.
Link the first mention of a product name when the destination helps the reader.
Do not rewrite product names for grammar or title-case rules.
Preserve third-party product names according to the owner's spelling.
Include the company name and full model qualifier on first use when it helps identify the model.
Preserve the official capitalization and punctuation of model names.
Use shorter family names only after the full model name is established.
For learning-oriented docs, technical blog posts, GTC sessions, tutorials, and developer guides: do not force trademark symbols unless the source, platform, or legal guidance explicitly requires them.
For learning-oriented docs, technical blog posts, GTC sessions, tutorials, and developer guides: keep the product name accurate and consistent.
For press releases, product landing pages, packaging, sales content, or legal copy: follow the current NVIDIA trademark and copyright guidance.
For press releases, product landing pages, packaging, sales content, or legal copy: attribute trademarks on first use when required.
For press releases, product landing pages, packaging, sales content, or legal copy: use the required trademark symbol for the specific product or service.
For press releases, product landing pages, packaging, sales content, or legal copy: do not invent trademark attributions; verify current legal copy.
If the platform requires legal copy, confirm the current source of truth instead...

Files:

• CONTRIBUTING.md

**/*.{md,mdx,rst}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-technical-docs.md)

**/*.{md,mdx,rst}: When reviewing technical documentation, verify that commands, examples, paths, APIs, and support claims match the current repository.
Make technical documents easy to scan by fixing headings, lead-in sentences, lists, tables, and procedure shape.
Preserve exact code, command, API, package, and UI strings unless they are factually wrong.
Prefer focused findings over broad rewrites.
Use title case consistently in technical documentation headings.
Avoid quotation marks, ampersands, and exclamation marks in technical documentation headings.
Keep product, event, research, and whitepaper names in their official title case.
Use title case for table headers.
Do not force social-media sentence case into technical documentation.
Format code elements, commands, parameters, package names, and expressions in monospace.
Format directories, file names, and paths in monospace.
Use angle brackets inside monospace for variables inside paths.
Format error messages and strings with quotation marks, using code formatting when that is clearer.
Format UI buttons, menus, fields, and labels in bold.
Use angle brackets between UI labels for menu paths.
Use italics on first use for new terms, and only when the term is introduced.
Italicize publication titles.
Write keyboard shortcuts in plain text.
Use Owner/repo link text for GitHub repositories.
Introduce every code block with a complete sentence.
Do not make a code block complete the grammar of the previous sentence.
Do not continue a sentence after a code block.
Use syntax highlighting when the format supports it.
Avoid the word "snippet" unless the surrounding documentation already uses it as a term of art.
Keep inline method, function, and class references consistent with nearby docs, and omit empty parentheses in prose when no call is shown.
Use descriptive anchor text that matches the destination title when possible.
Avoid raw URLs in running text.
Avoid generic anchors such as "here," "this page," and "read more....

Files:

• CONTRIBUTING.md

**/*.{md,mdx,rst,txt}

📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)

**/*.{md,mdx,rst,txt}: If documentation or examples changed, run just docs when practical and verify documented commands against the current repository.
For documentation-only changes, use contribute-docs and review-doc-style; run just docs for docs-site or generated-reference changes.

Files:

• CONTRIBUTING.md

**/*

📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)

For CI or packaging changes, use maintain-ci or maintain-packaging, then run the recipes and checks whose behavior changed.

Files:

• CONTRIBUTING.md

**/*.{rs,py,html,md,mdx,toml,yaml,yml,sh}

📄 CodeRabbit inference engine (CONTRIBUTING.md)

**/*.{rs,py,html,md,mdx,toml,yaml,yml,sh}: All source files must include an SPDX license header using the correct comment syntax for the file type.
Reviewers will check SPDX headers during review.

Files:

• CONTRIBUTING.md

🧠 Learnings (1)

📓 Common learnings

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: Use raw Rust-compatible SemVer release tags without a leading `v` (for example `0.1.0` or `0.1.0-rc.1`, not `v0.1.0`).

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: Run the relevant test suites for every language surface affected by your changes; if a change touches the Rust core or public schemas, run both the Rust and Python suites.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: Use `just test-rust`, `just test-python`, or `just test-all` through the repository `justfile` to run affected tests; use `no_uv=true` when the virtual environment is already synchronized.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: When adding functionality, include tests in the corresponding Rust crate or in the relevant area under `tests/`.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: Public contract changes must keep the checked-in JSON Schema snapshots and native Python binding declarations synchronized.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: If your change affects public behavior, adapters, examples, or workspace structure, update the corresponding documentation in the same branch.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: Before opening a PR, confirm the affected packages compile, update documentation entry points and references, and rebase your branch on the latest `main`.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: Complete the pull request template with an overview, reviewer starting point, related issues, testing, and breaking changes when applicable.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: All PRs require at least one approving review, CI must pass before merging, and review feedback should be addressed with additional commits rather than force-pushing during review.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: Use the commit message format `type: short description of the change`, keep the first line under 72 characters, and use the body for extra context when needed.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: Use a valid commit type from `feat`, `fix`, `docs`, `test`, `refactor`, `chore`, or `perf`.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-09T20:49:32.248Z
Learning: Every commit in a pull request must include a Developer Certificate of Origin sign-off.

🔇 Additional comments (1)

CONTRIBUTING.md (1)

164-172: 🎯 Functional Correctness

just build-rust, just build-python, and just build-all are defined in justfile.

			> Likely an incorrect or invalid review comment.

---

Walkthrough

Adds a new CONTRIBUTING.md with workflow guidance for setup, release tags, coding standards, testing, documentation updates, DCO sign-off, PR submission, commit messages, and SPDX license headers.

Changes

Contributing Documentation

Layer / File(s)	Summary
Intro and development setup CONTRIBUTING.md	Introduces the guide and describes package installation and source build setup.
Release tagging and code style CONTRIBUTING.md	Defines SemVer tagging rules and Rust/Python code style requirements.
Testing requirements and documentation checklist CONTRIBUTING.md	Lists testing requirements via just targets and a documentation update checklist.
DCO, PR process, and commit conventions CONTRIBUTING.md	Covers DCO sign-off, PR submission process/template, and commit message format/types.
SPDX license header requirements CONTRIBUTING.md	Specifies required SPDX headers with examples per file type.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• NVIDIA/NeMo-Fabric#34: Also adds contributor-facing workflow guidance, including PR preparation and validation steps.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description only includes confirmation checkboxes and omits the required Overview, reviewer start, and Related Issues sections.	Add the template sections: Overview, Where should the reviewer start?, and Related Issues, plus a brief summary of the documentation changes.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title follows Conventional Commits and clearly matches the contributor guide documentation change.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

📖 Fern docs preview: https://nvidia-preview-pull-request-48.docs.buildwithfern.com/nemo/fabric