[docs, ci] chore: add governance issue forms and triage guide

[yaoyu-33]

Summary

• replace legacy Markdown issue templates with structured GitHub issue forms for bug, feature, support, and model support requests
• document the repo's label taxonomy, area labels, and triage views in CONTRIBUTING.md
• align issue intake with existing labels such as needs-triage and needs-follow-up

Test plan

• pre-commit run
• Validate issue template YAML parsing locally
• Full CI not run locally

Made with Cursor

Summary by CodeRabbit

• Documentation
  • Migrated issue templates to structured YAML format for better issue submissions.
  • Added new support request template for standardized support inquiries.
  • Enhanced contributing guidelines with labeling taxonomy and triage governance.
  • Removed legacy markdown-based templates and replaced with guided forms.

[yaoyu-33]

/ok to test e0b3c8c

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[coderabbitai]

📝 Walkthrough

Walkthrough

GitHub issue templates are migrated from Markdown to YAML format for bug reports, feature requests, and model support requests. A new standardized support request template is introduced. CONTRIBUTING.md is updated with labeling and triage governance documentation.

Changes

Cohort / File(s)	Summary
Issue Template Migration .github/ISSUE_TEMPLATE/bug_report.md → .github/ISSUE_TEMPLATE/bug_report.yml, .github/ISSUE_TEMPLATE/feature_request.md → .github/ISSUE_TEMPLATE/feature_request.yml, .github/ISSUE_TEMPLATE/model-support-request.md → .github/ISSUE_TEMPLATE/model_support_request.yml	Converts three Markdown templates to YAML format with enhanced structure. YAML versions add form metadata, required/optional field designations, dropdown options, and validation rules. Bug template adds Affected area (model, recipe, training, etc.) and Regression dropdowns. Feature template adds Urgency dropdown. Model support template adds architecture-family dropdown and deliverables checklist.
New Support Request Template .github/ISSUE_TEMPLATE/support_request.yml	Introduces standardized YAML template for support requests with required fields (user-problem, desired-outcome, affected-area, urgency) and optional fields (alternatives, environment). Includes predefined options for categorization and severity levels.
Contributing Guidelines CONTRIBUTING.md	Adds comprehensive section on repository labeling and triage governance, including label taxonomy (Type, State, Risk, Area), application rules, triage workflows, and queue management guidance.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Test Results For Major Changes	✅ Passed	PR contains only configuration and documentation changes (GitHub issue templates and CONTRIBUTING.md) with no runtime code modifications.
Title check	✅ Passed	The title accurately describes the main change: replacing legacy markdown issue templates with structured GitHub issue forms and adding triage governance documentation to CONTRIBUTING.md.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch yuya/add-governance-issue-forms

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

🧹 Nitpick comments (1)

CONTRIBUTING.md (1)

201-247: Consider clarifying type vs. area for docs and ci.

Both docs and ci appear as type labels (lines 210-211) and as area labels (area:docs, area:ci at lines 244-245). While this may be intentional (type = what kind of work, area = what code domain), the overlap could confuse contributors.

Consider adding a brief clarification, e.g., "Use docs as a type when the PR is purely documentation; use area:docs as an area when a feature or bug also touches documentation."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@CONTRIBUTING.md` around lines 201 - 247, Add a short clarifying sentence in
the "Type Labels" / "Area Labels" section explaining the distinction and when to
use the overlapping labels: state that `docs` and `ci` are type labels to
classify the kind of work (e.g., documentation-only or CI/automation changes)
while `area:docs` and `area:ci` are area labels to indicate the code/domain
affected when a PR also modifies implementation; place this sentence adjacent to
the two tables and use the exact label names `docs`, `ci`, `area:docs`, and
`area:ci` so contributors see the mapping clearly.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@CONTRIBUTING.md`:
- Around line 201-247: Add a short clarifying sentence in the "Type Labels" /
"Area Labels" section explaining the distinction and when to use the overlapping
labels: state that `docs` and `ci` are type labels to classify the kind of work
(e.g., documentation-only or CI/automation changes) while `area:docs` and
`area:ci` are area labels to indicate the code/domain affected when a PR also
modifies implementation; place this sentence adjacent to the two tables and use
the exact label names `docs`, `ci`, `area:docs`, and `area:ci` so contributors
see the mapping clearly.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: d58d562b-3f3e-4f32-b38e-de989a0d415a

📥 Commits

Reviewing files that changed from the base of the PR and between a44fff2 and e0b3c8c.

📒 Files selected for processing (8)

• .github/ISSUE_TEMPLATE/bug_report.md
• .github/ISSUE_TEMPLATE/bug_report.yml
• .github/ISSUE_TEMPLATE/feature_request.md
• .github/ISSUE_TEMPLATE/feature_request.yml
• .github/ISSUE_TEMPLATE/model-support-request.md
• .github/ISSUE_TEMPLATE/model_support_request.yml
• .github/ISSUE_TEMPLATE/support_request.yml
• CONTRIBUTING.md

💤 Files with no reviewable changes (3)

• .github/ISSUE_TEMPLATE/bug_report.md
• .github/ISSUE_TEMPLATE/model-support-request.md
• .github/ISSUE_TEMPLATE/feature_request.md

[yaoyu-33]

/ok to test 31c3e56

[yaoyu-33]

/ok to test 8296146

[cuichenx]

is it still necessary to write tags in the PR title if we have the appropriate labels as you outlined below?

[yaoyu-33]

just recommendation, to keep it very clear in git history

[cuichenx]

suggest renaming to "waiting-for-author"

[yaoyu-33]

/ok to test f820300