NVIDIA NeMo Respond to a GitHub issue
Draft a high-quality maintainer response to an issue on NVIDIA-NeMo/Lens,
grounded in what the code actually does.
Most questions here come from users of a library they did not choose directly — lens arrives as an optional dependency of Megatron-LM, NeMo-RL, or NeMo-Gym. Assume the reporter knows their own framework well and lens barely at all.
1. Read the issue
gh issue view <number> --repo NVIDIA-NeMo/Lens --json title,body,comments,labels,state,author
Read the body and every existing comment before forming a view. Classify it —
the templates label them bug, enhancement, or question — and note which
consumer repo the reporter is coming from, since that usually determines the
answer.
2. Route it
Most questions land in one of a few buckets. Check the likely cause before reading code at random:
| Symptom | Look first at |
|---|---|
| "No spans / nothing exported" | NEMO_LENS_ENABLED is false by default; then check whether the caller left enabled false on this rank (lens does no rank filtering of its own) |
| "Works locally, nothing in my backend" | OTEL_EXPORTER_OTLP_* is the SDK's business, not lens's; check their endpoint before reading lens code |
| "Some spans missing" | span groups — default is only job, checkpoint, evaluate. They likely want per_step or all |
| "ImportError / no-op behavior" | the optional-dependency contract — docs/design/optional-dependency.mdx, fallbacks.py |
| "Attribute or metric I expected isn't there" | semconv.py for the real name; then whether it's classified as a resource attribute, span attribute, or metric |
| "Colliding trace IDs across ranks" | SeedIndependentIdGenerator — a known, fixed bug worth linking |
| "How do I add X to my repo" | it's a consumer-side question; point at their telemetry/ package, not lens |
3. Research the code
- Search
src/nemo/lens/for the relevant module — the layout table inAGENTS.mdsays which file owns what. - Read the source. Do not answer a behavior question from the docs alone; the docs are authoritative for intent, the code for what shipped.
git log --oneline -20 -- <files>— was this recently changed or already fixed?git log -S "<symbol>" --oneline— when did this appear or disappear? Useful for "why is this gone" and "was this ever supported".- Check whether a PR is already in flight:
gh pr list --repo NVIDIA-NeMo/Lens --search "<keywords>" --limit 5 - Check for related issues:
gh issue list --repo NVIDIA-NeMo/Lens --search "<keywords>" --limit 5 --state all
If the report involves a released version, check whether the behavior differs
from main — package_info.py carries the version, and the docs are split
between nightly (docs/) and the frozen 0.1.0 snapshot.
4. Verify before citing
Every concrete claim in the draft gets checked:
- Citing a file and line? Re-read it and confirm the line says what you claim.
- Citing a commit?
git show <sha> --statand confirm it does what you say. - Claiming something is unused, missing, or unsupported? Grep thoroughly enough to be sure — a wrong "that's not supported" from a maintainer is expensive.
- Quoting an env var? Confirm the exact name and prefix in
config.py. TheUSER_IDkey maps to theuserfield; that mismatch is easy to get wrong. - Recommending a config? Confirm the default in the
from_env()table.
5. Draft
Write a reply that:
- Answers the actual question first, in the first line or two.
- Cites
file:linewhere it helps the reader verify you. - Acknowledges a real bug or gap plainly when the reporter found one. They did you a favor; say so.
- Gives the workaround if one exists, even a clumsy one.
- Says whether a fix is planned, and that a PR would be welcome if it would be.
- Stays short. Contributors want an answer, not an essay.
- Stays welcoming — many reporters are first-time contributors to an NVIDIA repo.
If the honest answer is "that's a Megatron-LM / NeMo-RL / NeMo-Gym question", say so and point at the right repo, but answer the lens-shaped part first rather than bouncing them cold.
6. Offer the follow-up
If the issue exposes something cleanly actionable — a doc page that is wrong, a missing fallback signature, a one-line fix — tell the maintainer and offer to open a branch and PR. Don't stop at drafting a comment when the fix is small.
If it touches the public surface — __all__, a fallbacks.py signature, a
NemoLensConfig field, a SpanRegistry method — say so explicitly. The
consumer mirror obligation applies (Megatron-LM, NeMo-RL, NeMo-Gym each carry
their own copy of that contract) and it is easy to forget from an issue thread.
7. Hand the draft back
Show the draft to the maintainer as a fenced markdown block they can copy. Do not post it. Posting is the maintainer's decision, always.
Guidelines
- Never post or edit anything on GitHub without explicit approval.
- Flag your own uncertainty in the draft rather than smoothing it over — the maintainer needs to know which parts they are vouching for.
- If the code cannot settle the question, say what you established and what remains open. That is a useful answer; a confident wrong one is not.
- Don't promise a timeline, a release, or a roadmap position on the project's behalf.