Evaluate GitHub issue templates for common report types

[aoirint]

Warning

This issue was created with assistance from LLMs.

Summary

• Follow up from docs: add issue reporting guidance #86 by evaluating whether this repository should add GitHub issue templates.
• The decision in docs: add issue reporting guidance #86 was to keep issue-template design out of that PR's scope.
• This issue tracks the separate intake-design work, if maintainers decide templates would help.

Details

• docs: add issue reporting guidance #86 adds general issue-reporting guidance to CONTRIBUTING.md and links the Thunderstore-facing changelog to that guidance.
• A reviewer/user question raised whether common GitHub issue templates should also be considered.
• Follow-up classification note from docs: add issue reporting guidance #86:
  • Feature requests are a distinct public issue category and should be named explicitly.
  • Compatibility notes are useful enough for this project to remain a named issue category.
  • Documentation improvement requests should align with the existing CONTRIBUTING.md wording that welcomes documentation improvements, without implying pull requests are discouraged.
  • Release-note corrections can usually be treated as documentation improvement requests.
• Public issue material note from docs: add issue reporting guidance #86:
  • docs: add issue reporting guidance #86 keeps ordinary issue reports lightweight. Logs, screenshots, ideas, bug reports, and reproduction context do not need a CLA confirmation just because they are shared in a public issue.
  • Maintainers may use public supporting material within a reasonable scope related to the reported issue, including for understanding, reproducing, discussing, fixing, and communicating with end users about it.
• Direct-inclusion or adaptation material note from docs: add issue reporting guidance #86:
  • docs: add issue reporting guidance #86 warns users not to submit sample code, documentation text, patches, or other material that could be included or adapted into the project unless they provide it under the Contribution License Agreement.
  • docs: add issue reporting guidance #86 now asks users to clearly state the same confirmation used for pull requests when submitting that material: I have read CONTRIBUTING.md and agree to the Contribution License Agreement.
  • This is meant to cover material that may be copied directly or adapted before inclusion, while leaving ideas, bug reports, logs, screenshots, and reproduction context lightweight.
  • If issue templates are added, they should avoid requiring CLA confirmation for every issue. Instead, use the checkbox only in templates or sections that intentionally collect material that could be included or adapted into the project.
• Recent issue history includes several report/task shapes, including:
  • Bug reports or behavior reports.
  • Feature requests.
  • Compatibility notes.
  • Documentation improvement requests, including release-note corrections.
  • Maintenance, refactor, and follow-up tasks.
  • Security or supply-chain process work.
• Security-sensitive reports should remain separate from public issue templates and follow private reporting guidance.

Acceptance Criteria

• Review recent repository issues and identify the common public issue categories worth templating.
• Decide whether issue templates are useful for the current repository size and maintainer workflow.
• If templates are useful, add a small template set rather than one oversized generic template.
• Consider templates such as:
  • Bug report.
  • Feature request.
  • Compatibility note.
  • Documentation improvement request, covering release-note corrections when applicable.
  • Maintenance or follow-up task.
• Decide which templates, if any, should collect material that could be included or adapted into the project.
• For templates that may collect such material, consider a CLA confirmation checkbox using the exact wording already used by the pull request template and docs: add issue reporting guidance #86 guidance: I have read CONTRIBUTING.md and agree to the Contribution License Agreement.
• Keep ordinary report templates lightweight and avoid making users confirm the CLA for ideas, bug reports, logs, screenshots, or reproduction context alone.
• Keep security reporting out of public templates, or make any public security guidance redirect reporters away from public details.
• Update CONTRIBUTING.md if the final template workflow changes how users should report issues.

Verification

• Updated from the docs: add issue reporting guidance #86 review follow-up after commit 0d6248f clarified the public-material wording, the exact CLA confirmation phrase, and the softer Thunderstore changelog route.
• No issue-template implementation has been attempted yet.