Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions CODE_OF_CONDUCT.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Code of Conduct

## Our Pledge

The NeMo Curator project is committed to providing a welcoming, respectful, and harassment-free experience for everyone who participates in our community — in issues, pull requests, discussions, code reviews, events, and any other project space.

## Our Standard

This project adopts the **[Contributor Covenant, version 2.1](https://www.contributor-covenant.org/version/2/1/code_of_conduct/)** as its Code of Conduct. The full text is published at the link above and is incorporated here by reference.

In short:

- **Be respectful.** Treat other contributors with empathy, kindness, and patience. Assume good intent and prefer constructive feedback.
- **Be inclusive.** Welcome newcomers and people from all backgrounds. Use language that everyone can engage with.
- **Be collaborative.** Disagreements happen — keep them about the work, not the person. Defer to maintainers on direction.
- **Be accountable.** Take responsibility for mistakes, apologize when appropriate, and learn from the experience.

## Scope

This Code of Conduct applies in all official project spaces — the GitHub repository (issues, pull requests, discussions, code review), associated chat and event spaces, and any time an individual is representing the project in public. It also applies when project participants interact in private channels if that conduct affects the safety or well-being of community members.

## Reporting

If you experience or witness behavior that violates this Code of Conduct, please report it to the maintainers so we can address it. We accept reports through either of the following channels:

- **Open a private report on GitHub** by using [Report abuse](https://github.com/contact/report-abuse) and selecting *Report content to GitHub* → *I want to report abusive content or behavior* → the relevant repository or user. GitHub forwards the report to the repository's maintainers and to GitHub Trust & Safety.
- **Contact a repository maintainer directly** via GitHub (DM or `@`-mention on a private discussion). Maintainers are listed in the repository's commit history and on the [contributors page](https://github.com/NVIDIA-NeMo/Curator/graphs/contributors).

A dedicated reporting email will be added here once confirmed with the project's open-source program office; until then, the GitHub channels above are the supported route.

All reports will be reviewed and investigated promptly and fairly. Maintainers are obligated to respect the privacy and security of the reporter of any incident.

## Enforcement

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Unresolved TODO placeholder blocks actionable reporting

The reporting contact is still <TODO: confirm reporting contact — e.g., sw-coc@nvidia.com>. A CoC with no reachable enforcement channel is worse than none — reporters cannot escalate violations, and the file ships with raw angle-bracket template syntax visible to every contributor. The PR description flags OSPO sign-off as required; this should be a hard merge gate, not a follow-up.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 06748dd — removed the <TODO> placeholder. Reports now route through GitHub-native channels (Report abuse + direct maintainer contact), which are reachable today without OSPO sign-off. A dedicated email alias can be swapped in later when confirmed; no longer a merge blocker.

Maintainers are responsible for clarifying and enforcing this Code of Conduct and will take appropriate, fair corrective action in response to any behavior they deem inappropriate, threatening, offensive, or harmful. Enforcement follows the **[Contributor Covenant Enforcement Guidelines](https://www.contributor-covenant.org/version/2/1/code_of_conduct/#enforcement-guidelines)**, which describe a graduated set of responses ranging from a private warning to a permanent ban.

## Attribution

This Code of Conduct is adapted from the [Contributor Covenant, version 2.1](https://www.contributor-covenant.org/version/2/1/code_of_conduct/). Community Impact Guidelines are inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).

For answers to common questions about this Code of Conduct, see the FAQ at <https://www.contributor-covenant.org/faq>. Translations are available at <https://www.contributor-covenant.org/translations>.
85 changes: 64 additions & 21 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,30 +1,73 @@
# Checklist

We are glad you are contributing to NeMo Curator! Before you make a PR, be sure to read over this guide in detail.
This project will only accept contributions under the project's Apache2 license.
This checklist ensures that NeMo Curator stays easy-to-use by both users and developers.
Not all steps are necessary for some contributions, so read the linked sections for more information about each item.

- [Checklist](#checklist)
- [General principles](#general-principles)
- [Python style](#python-style)
- [Setup and Dev](#setup-and-dev)
- [Prerequisites](#prerequisites)
- [Installation](#installation)
- [Unit tests](#unit-tests)
- [Coverage](#coverage)
- [Pull Requests (PR) Guidelines](#pull-requests-pr-guidelines)
- [Updating Package Dependencies](#updating-package-dependencies)

## General principles
# Contributing to NeMo Curator

We're glad you're contributing to NeMo Curator. This guide explains what kinds of contributions we accept, where to ask questions, how to find a good first issue, and how to set up your environment and open a PR.

All contributions are accepted under the project's [Apache License 2.0](LICENSE). All participants are expected to follow our [Code of Conduct](CODE_OF_CONDUCT.md).

## Table of Contents

- [Ways to Contribute](#ways-to-contribute)
- [Your First Contribution](#your-first-contribution)
- [Asking Questions and Discussing Changes](#asking-questions-and-discussing-changes)
- [Code of Conduct](#code-of-conduct)
- [General Principles](#general-principles)
- [Python Style](#python-style)
- [Setup and Dev](#setup-and-dev)
- [Prerequisites](#prerequisites)
- [Installation](#installation)
- [Unit Tests](#unit-tests)
- [Coverage](#coverage)
- [Pull Requests (PR) Guidelines](#pull-requests-pr-guidelines)
- [Updating Package Dependencies](#updating-package-dependencies)

## Ways to Contribute

Contributions of any size are welcome. Common types:

- **Bug fixes** — reproducible issues with a failing test where practical.
- **Documentation** — fixes, clarifications, and new tutorials in `fern/` (the canonical docs source) and the in-repo `tutorials/` directory.
- **Tests** — extending unit, integration, or GPU test coverage; converting flaky tests into deterministic ones.
- **New pipeline stages** — modality-aware filters, classifiers, dedupers, loaders, or writers that fit the existing `Stage`/`Pipeline` abstractions.
- **Recipes and examples** — end-to-end curation workflows that exercise real datasets.
- **Performance work** — benchmarks, scaling improvements, or executor enhancements (please include before/after numbers).
- **Build, CI, packaging, and dependency hygiene.**

If you're planning a larger change (new modality, new executor, breaking API change), please open a [Discussion](https://github.com/NVIDIA-NeMo/Curator/discussions) or a draft issue first so we can align on direction before you invest in code.

## Your First Contribution

New to the project? Start here:

1. Browse issues labeled [`good first issue`](https://github.com/NVIDIA-NeMo/Curator/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) — these are scoped to be approachable without deep familiarity with the codebase.
2. Comment on the issue to claim it before you start work, so we don't duplicate effort.
3. Read [General Principles](#general-principles) and follow the [PR Guidelines](#pull-requests-pr-guidelines) below.

Good starter areas if no labeled issue catches your eye: docs typos and clarifications, missing docstrings, additional unit-test coverage, and small isolated Python-stage fixes.

## Asking Questions and Discussing Changes

| You want to… | Where to go |
|--------------|-------------|
| Ask a "how do I…" or "is this supported?" question | [GitHub Discussions](https://github.com/NVIDIA-NeMo/Curator/discussions) |
| Propose a non-trivial feature or design change | Open a Discussion or a draft Issue describing the design first |
| Report a reproducible bug | [GitHub Issues](https://github.com/NVIDIA-NeMo/Curator/issues) using the bug template |
| Show off a recipe or pipeline | Discussions → "Show and tell" |

These are community channels staffed on a best-effort basis; there is no support SLA. Please avoid opening Issues for usage questions — keep Issues focused on bugs and concrete proposals so the backlog stays tractable.

## Code of Conduct

This project follows the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). By participating — in issues, discussions, PRs, or any other project space — you agree to abide by its terms. To report unacceptable behavior, follow the reporting instructions in `CODE_OF_CONDUCT.md`.

## General Principles
1. **User-oriented**: make it easy for end users, even at the cost of writing more code in the background
1. **Robust**: make it hard for users to make mistakes.
1. **Reusable**: for every piece of code, think about how it can be reused in the future and make it easy to be reused.
1. **Readable**: code should be easier to read.
1. **Legal**: if you copy even one line of code from the Internet, make sure that the code allows the license that NeMo Curator supports. Give credit and link back to the code.
1. **Sensible**: code should make sense. If you think a piece of code might be confusing, write comments.

## Python style
## Python Style
We use ``ruff`` as our style guide. To fix your format run `pre-commit install && pre-commit run --all`.

**Setting up pre-commit hooks locally (optional)** (one-time setup):
Expand Down Expand Up @@ -81,7 +124,7 @@ uv sync --extra all

- If project dependencies are updated, the lock file needs to be regenerated. See [Updating Package Dependencies](#updating-package-dependencies) for the full workflow.

## Unit tests
## Unit Tests
Unit tests should be simple and fast.
Developers should be able to run them frequently while developing without any slowdown.
```
Expand Down
Loading
Loading