Create GitHub templates for issues and pull requests

[ahmedbektic]

Summary

This PR follows the new repository PR template and consolidates GitHub contribution template improvements for issues and pull requests.

What changed

• Enhanced .github/ISSUE_TEMPLATE/bug_report.yml:
• Added required Version/Commit field for reproducibility.
• Added required Severity dropdown (Low, Medium, High, Critical).
• Simplified logs placeholder so render: shell is used cleanly.
• Enhanced .github/ISSUE_TEMPLATE/feature_request.yml:
• Added required Acceptance Criteria section.
• Added optional Stretch Acceptance Criteria section.
• Kept/used requester-facing impact prioritization as User Impact Rating.
• Upgraded .github/ISSUE_TEMPLATE/good_first_issue.md:
• Added clearer structure for Summary, Problem / User Impact, Scope, Estimated Effort, Where to Start, Acceptance Criteria, and Definition of Done.
• Upgraded PR template content:
• Expanded sections for linked issue, scope, AC verification, test evidence, risk/rollback, and reviewer focus.
• Introduced multi-template PR folder and preserved default behavior:
• Added .github/PULL_REQUEST_TEMPLATE/pull_request_template.md.
• Restored default .github/pull_request_template.md copy so PRs auto-load template by default.
• Added capstone task issue form:
• Created .github/ISSUE_TEMPLATE/capstone_sprint_task.yml with sections for Intro, Overview (Given/When/Then), Currently, Description, essential/stretch AC, notes, next steps, resources, and author checklist.

Why

• Improve issue quality and triage speed.
• Make requests more testable with explicit acceptance criteria.
• Standardize sprint task authoring for capstone workflows.
• Improve PR review quality with AC verification and risk/test evidence.
• Support both default PR template behavior and future multi-template expansion.

How

• Edited existing YAML/Markdown templates directly.
• Kept formats aligned to GitHub-supported issue/PR template conventions.
• Applied content-focused changes only (no app/runtime code changes).

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code refactoring
• Performance improvement
• Test addition/update

Scope

In Scope

• GitHub issue template quality and structure improvements.
• PR template quality and placement adjustments.
• Capstone sprint issue-form template authoring.
• Template guidance updates based on maintainer workflow questions.

Out of Scope

• GitHub Discussion category form configuration in repository settings UI.

Testing

• I have tested my changes locally
• I have added/updated unit tests
• I have added/updated integration tests
• All existing tests pass
• I have tested with Docker setup
• I have tested with local development setup

Additional Context

Notes based on discoveries made during implementation:

Dynamic AC behavior:

• GitHub issue forms do not support dynamic repeatable form controls.
• Using textarea checklists for AC/Stretch AC is the practical approach for variable-length criteria.

Issue template format:

• .md is valid for classic issue templates (free-form).
• .yml is valid for structured issue forms (validated fields/dropdowns/checkboxes).

PR template placement:

• .github/pull_request_template.md is the default auto-applied PR template path.
• .github/PULL_REQUEST_TEMPLATE/*.md supports multi-template organization/selection.
• This PR keeps both so default behavior remains while multi-template structure is ready.

Discussion templates:

• Discussion category templates are category-based and managed with GitHub Discussions configuration; they are not the same as issue templates.

Reviewer Focus

• Confirm template language is clear, objective, and appropriate for student contributors.
• Confirm AC/Stretch AC structure meets maintainers’ triage and review workflow.
• Confirm keeping both default and multi PR template paths matches repository policy.
• Confirm capstone task structure aligns with sprint planning and grading expectations.

[CharlieWells13]

Looks good thanks for everything.

The only issue that I have is that pull_request_template seems to be added twice, please remove the duplication and then i will merge.

[ahmedbektic]

Yeah I probably shouldn't have done that. Since there is only one template the active one would be .github/pull_request_template.md. My rationale was if later someone wanted to add additional PR templates they'd be able to do so by simply adding them to .github/PULL_REQUEST_TEMPLATE/ folder, but I guess they could also create the folder for themselves

[CharlieWells13]

nice