Add bug report and feature request issue templates - #988
Conversation
.github had a pull-request template and nothing for issues, so a new issue opened as an empty box and arrived without the version, platform, provider, or model needed to start on it. The bug report is an issue form, so version, platform, install method, reproduction, and whether it reproduces on a clean config are required rather than suggested. Provider and model are required too, answerable with "not inference" — the field only costs something when it matters. The feature request stays markdown: a form there is friction on someone doing us a favour. Blank issues stay enabled. Discussions is not turned on for this repository, so disabling them would leave anyone with a question pushed into the wrong template. Templates link to CONTRIBUTING.md rather than restating it, and route security reports to private disclosure. CL-7890
076a864 to
07cc82a
Compare
TheGreatAxios
changed the title
Provider and model was marked required while its own description told non-inference reporters to type "not inference" to get past it. GitHub issue forms have no conditional-required, so that combination just forces boilerplate. It is optional now, with the description doing the asking. Install method comes off the required list for the same reason: it is rarely what unblocks a triager, and gating submission on it buys noise. "What happened" and the reproduction box were collecting the same paragraph twice; the first now asks only for the observed behavior. Four fields still gate submission: what happened, what was expected, reproduction, and version — plus platform and the clean-config answer. CL-7890
Audit — ApproveFit: this PR fills a real gap ( One fix applied (pushed to this branch as Stale-body-text note for the author: the PR body says provider/model are "required but answerable" — the form as merged makes provider-model optional (no |
1 participant
Closes CL-7890.
Summary
.github/hadPULL_REQUEST_TEMPLATE.mdandworkflows/and nothing else, so a new issue opened as an empty box. What arrived was whatever the reporter thought to include — usually not the version, platform, provider, or model a triager needs before starting.What is here
bug-report.yml— an issue form, so the fields are required rather than suggested: what happened, what was expected, steps to reproduce,corbits --version, OS/arch, install method, provider and model, relevant output, and whether it reproduces on a clean config.Provider and model are required but answerable with "not inference" — the field only costs something when it matters, and inference bugs are unactionable without it. The clean-config dropdown is the single most useful thing a reporter can tell us, so it is required too.
feature-request.md— markdown, deliberately. A form here is friction on someone doing us a favour. Asks for the problem before the solution, the current workaround, and what they already ruled out.config.yml— routes security reports to private disclosure, plus links todocs/andCONTRIBUTING.md.Two judgement calls
Blank issues stay enabled. I disabled them first, then checked:
has_discussionsisfalseon this repo. Disabling blank issues with no Discussions leaves anyone with a question pushed into the wrong template. There is a comment inconfig.ymlsaying to turn it off if Discussions is ever enabled.No Discussions link. My first draft linked to
/discussions, which would have been a dead 404 for the same reason.Constraint honored
Templates link to
CONTRIBUTING.mdrather than restating any of it. Nothing here describes commit or PR conventions, which are changing under #985 and would have gone stale immediately.The bug report also warns against pasting credentials or
~/.corbits/settings.jsoncontents — worth having on a tool whose config file holds provider API keys.Testing
Both YAML files parse. Rendering in the GitHub new-issue picker cannot be verified until the branch is on the default branch — that Outcome item stays unticked.