add issue & PR templates #16
Conversation
WalkthroughAdded three GitHub template files (bug report, feature request, pull request) and updated the CI workflow to ignore those template paths for push and pull_request events. Templates define metadata and structured form fields for issue/PR submission. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: defaults Review profile: CHILL Plan: Pro 📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (2)
🔇 Additional comments (5)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the 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. Comment |
|
Do you mind updating the paths to ignore in the CI workflows to include these templates? You'll have to add it to: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/ISSUE_TEMPLATE/feature_request.yml (1)
42-56: Consider making Component dropdown required.While the Component dropdown has a good selection of options, making it required could improve issue triage and routing. This would ensure all feature requests are properly categorized.
🔎 Proposed change to make Component required
- type: dropdown id: component attributes: label: Component description: Which part of Cordon does this affect? options: - CLI Interface - Python API - Embedding Backends - Scoring/Analysis - Output Formatting - Container/Deployment - Documentation - Other + validations: + required: true
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/ISSUE_TEMPLATE/bug_report.yml(1 hunks).github/ISSUE_TEMPLATE/feature_request.yml(1 hunks).github/PULL_REQUEST_TEMPLATE.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
.github/PULL_REQUEST_TEMPLATE.md
[style] ~9-~9: Consider using a different verb for a more formal wording.
Context: ... ] 🐛 Bug fix (non-breaking change that fixes an issue) - [ ] ✨ New feature (non-brea...
(FIX_RESOLVE)
[style] ~41-~41: Consider using a different verb for a more formal wording.
Context: ...ve run pre-commit run --all-files and fixed any issues - [ ] I have updated the doc...
(FIX_RESOLVE)
🔇 Additional comments (7)
.github/PULL_REQUEST_TEMPLATE.md (1)
1-48: LGTM! Comprehensive and well-structured PR template.The template covers all essential aspects of a pull request:
- Clear categorization of change types
- Testing requirements including pytest and manual validation
- Quality enforcement through ruff and pre-commit checks
- Appropriate use of placeholders for contributors to fill in
The static analysis hints about verb choice ("fixes" and "fixed") are false positives in this context—the wording is appropriate for a PR template.
.github/ISSUE_TEMPLATE/feature_request.yml (2)
1-41: LGTM! Well-structured metadata and core fields.The feature request template has:
- Clear metadata with appropriate labels
- Required fields for Problem Statement and Proposed Solution with helpful placeholders
- Optional Alternatives Considered field for thoughtful feature proposals
The structure guides users to provide comprehensive feature descriptions.
57-80: LGTM! Well-designed optional fields.The Priority dropdown, Contribution checkbox, and Additional Context fields appropriately remain optional, allowing contributors flexibility while still gathering useful triage information.
.github/ISSUE_TEMPLATE/bug_report.yml (4)
1-49: LGTM! Comprehensive bug description fields.The template metadata and core fields are well-structured:
- Appropriate labels for bug tracking and triage
- Clear separation between bug description, reproduction steps, expected behavior, and actual behavior
- All critical narrative fields are marked as required
- Helpful placeholders guide users to provide actionable information
50-87: LGTM! Thorough version and OS information collection.The template appropriately requires:
- Cordon and Python versions (essential for reproducibility)
- Operating system selection with comprehensive options including containers
- Optional OS version for additional context
The placeholders clearly show users what information to provide and how to retrieve it.
88-118: LGTM! Well-designed backend and acceleration fields.The template effectively captures Cordon-specific technical environment:
- Backend dropdown covers the main embedding backends (sentence-transformers, llama-cpp, remote)
- Device/Acceleration dropdown includes CPU, CUDA, MPS, Vulkan, and auto-detection
- GPU model is appropriately optional and conditional
This information is essential for diagnosing backend-specific and acceleration-related issues.
119-130: LGTM! Appropriate optional diagnostic fields.The template concludes with well-designed optional fields:
- Error logs textarea with
render: shellfor proper formatting of stack traces- Additional context field for edge cases and supplementary information
These optional fields allow users to provide rich diagnostic details without being overly prescriptive.
Assisted-by: Cursor Signed-off-by: Adam Scerra <ascerra@redhat.com>
ascerra
force-pushed
the
add-issue-pr-templates
branch
from
e27830b to
136ae97
Compare
|
2 participants
Description
Add GitHub issue templates and a pull request template to help standardize contributions and bug reports as the project grows.
Type of Change
Changes Made
Add Bug Report issue template (
bug_report.yml) with structured fields for:Add Feature Request issue template (
feature_request.yml) with fields for:Add Pull Request template with:
Preview
You can see these templates in action on my fork:
Why This Matters
As Cordon gains traction, these templates will:
Assisted-by: Cursor
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.