Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
136 lines (92 loc) · 7.84 KB

CONTRIBUTING.md

File metadata and controls

136 lines (92 loc) · 7.84 KB
Raw

🎨✨ Contributing to NeMo Data Designer 🎨✨

The skills and workflows in this repository are for developing DataDesigner. If you're looking to use DataDesigner to build datasets, see the product documentation instead.

This project uses agent-assisted development. Contributors are expected to use agents for investigation, planning, and implementation. The repository includes skills and guidance that make agents effective contributors.

Agents accelerate work; humans stay accountable. People make design decisions and own quality — agents help get there faster.

How to Contribute

  1. Open an issue using the appropriate issue template.
  2. Include investigation output. If you used an agent, paste its diagnostics. If you didn't, include the troubleshooting you tried.
  3. For non-trivial changes, create a plan document at plans/<issue-number>/ before building. Have your agent draft the plan — it should describe the approach, trade-offs considered, affected subsystems, and a delivery strategy. See existing plans in plans/ for reference. Submit the plan in a PR for review.
  4. Once the plan is approved, implement using agent-assisted development. See DEVELOPMENT.md for local setup and workflow.

Before You Open an Issue

  • Clone the repo and point your agent at it
  • Have the agent search docs and existing issues (the search-docs and search-github skills can help)
  • If the agent can't resolve it, include the diagnostics in your issue
  • If you didn't use an agent, include the troubleshooting you already tried

When to Open an Issue

  • Real bugs — reproduced or agent-confirmed
  • Feature proposals with design context
  • Problems that search-docs / search-github couldn't resolve

When NOT to Open an Issue

  • Questions about how things work — an agent can answer these from the codebase
  • Configuration problems — an agent can diagnose these
  • "How do I..." requests — try the product documentation first

Development Skills

The repository includes skills for common development tasks. These are located in .agents/skills/ and are automatically discovered by agent harnesses.

Category Skills Purpose
Investigation search-docs, search-github Find information, check for duplicates
Development commit, create-pr, update-pr Standard development cycle
Review review-code Multi-pass code review

Pull Requests

Issue triage for external pull requests

Before submitting a PR, link it to an existing, open issue that a maintainer has reviewed and labeled triaged. Open an issue and wait for that label if needed. Use Fixes #NNN, Closes #NNN, or Resolves #NNN in the PR description.

A newly opened or reopened external PR without an open, triaged issue is automatically closed. Check the issue for the triaged label; after a maintainer adds it, you may reopen the PR. Later changes to the issue re-run the linked-issue check but do not automatically close a PR already under review. A maintainer can add keep-open to exempt a PR from automatic closure. Repository collaborators and the exempt automation bots are not subject to this requirement.

  • PRs with failing checks that remain inactive are automatically reminded after 7 days and closed after 14 days (collaborators: 14/28 days). Push an update or leave a comment to reset the timer. If you need more time, ask a maintainer to add the keep-open label.
  • Use the create-pr skill for well-formatted PR descriptions, or follow the PR template
  • Ensure all checks pass before requesting review: 
    make check-all-fix
make test
  • Run a self-review before opening the PR using the review-code skill. Address any critical or warning-level findings before requesting human review. If you have access to multiple models, run the review with different models across passes — different models surface different issues, and a single pass rarely catches everything.

Pull Request Review Process

  • Autobot runs comment-only reviews for same-repository PRs when opened non-draft or marked ready for review.
  • Maintainers can request a fresh review by posting /review model=claude mode=strict reset=true on the PR. Manual requests support model=claude|codex and mode=light|strict; automatic reviews use the default model and the repository profile's default mode.
  • Fork PRs require maintainer vetting and a copy-pr-bot mirror before Autobot can review them. A maintainer inspects the current head and posts /ok to test <full-head-sha>. This also authorizes mirrored CI in the upstream repository, where workflows can access repository secrets. Inspect executable code and workflow changes before approving. Once the mirror matches, a pending automatic review for that head can proceed; otherwise request one with /review. After new commits, repeat vetting and request a fresh review.
  • If an automated review is posted, address its critical and warning-level findings before requesting human review. Linting and tests run separately in normal CI.
  • Maintainers will review your PR and may request changes
  • Address feedback by pushing additional commits to your branch
  • Reply to each comment before resolving it. If the comment resulted in a code change, include the commit hash that addresses it. Do not resolve comments without a response.
  • Once approved, a maintainer will merge your PR

The repository rubric lives in .github/review-policy/SKILL.md. Autobot must be configured to use this rubric; check the review output to confirm the selected rubric and settings.

Documentation Changes

Data Designer docs are Fern-first. The legacy MkDocs archive remains frozen on GitHub Pages for releases 0.5.7 and older.

  • Edit docs prose under fern/.
  • Edit tutorial notebooks in docs/notebook_source/*.py.
  • Use make serve-fern-docs-locally to preview the Fern site.
  • Use make check-fern-docs to regenerate local Fern artifacts and validate the Fern site.
  • Fern release publishing snapshots versioned docs into the CI-managed docs-website branch automatically.
  • Do not commit generated notebook artifacts.

Commit Messages

  • Use imperative mood ("add feature" not "added feature")
  • Keep the subject line under 50 characters (hard limit: 72)
  • Reference issue numbers when applicable (Fixes #123)

License Headers

All code files must include the NVIDIA copyright header:

# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
# SPDX-License-Identifier: Apache-2.0

Use make update-license-headers to add headers automatically.

Signing Off on Your Work (DCO)

When contributing, you must agree that you have authored 100% of the content, that you have the necessary rights to the content, and that the content you contribute may be provided under the project license. All contributors are asked to sign the Developer Certificate of Origin (DCO) when submitting their first pull request. The process is automated by a bot that will comment on the pull request.

Code of Conduct

Data Designer follows the Contributor Covenant Code of Conduct. Please read our complete Code of Conduct for full details.

Reference

  • AGENTS.md — architecture, layering, design principles
  • STYLEGUIDE.md — code style, naming, imports, type annotations
  • DEVELOPMENT.md — local setup, testing, day-to-day workflow