Repository navigation
Add GitHub intake templates and align process docs - #1333
Conversation
Corrects CONTRIBUTING, the pull request checklist and the release guide to describe how the project works, and adds issue forms and a pull request template under .github/ that ask whether a change could make a failing test appear to pass. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
mvandervoord
left a comment
mvandervoord
left a comment
There was a problem hiding this comment.
This is definitely something to mull over a bit. I've worked on other projects which have added checklists and forms and whatnot to issues, PR's, etc. I've not once thought "that was helpful." I've frequently felt like it was unnecessarily wordy, complex, or insulting. It has more than once convinced me to not submit an issue for projects. I suspect I'm not alone. I love providing documentation and guidelines for encouraging people to submit valuable issues / PR's.... but as soon as it's extra steps they are required to take, I think it's a negative. At that point, I'd rather get incomplete information than no information (because they were turned off).
This is a great place for people to tell me why I'm wrong. I can take it. ;)
There was a problem hiding this comment.
"Please check that you are using the latest release" is an unreasonable request for a tool like this. I would say most users are not going to be in a position to use the latest. They are going to be using whatever version their department has decided to use for this project, which will be held back by momentum, compliance, validation, upgrade policies, etc. Instead, maybe we note something about verifying that the issue hasn't already been resolved if they're still on an older release?
| attributes: | ||
| label: Before submitting | ||
| options: | ||
| - label: I searched existing issues and did not find this problem. |
| attributes: | ||
| label: Before submitting | ||
| options: | ||
| - label: I searched existing issues and did not find this request. |
| - **Prefer using [reactions](https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)**, not comments, if you simply want to "+1" an existing issue. | ||
|
|
||
| - **Fully complete the provided issue template.** The bug report template requests all the information we need to quickly and efficiently address your issue. Be clear, concise, and descriptive. Provide as much information as you can, including steps to reproduce, stack traces, compiler errors, library versions, OS versions, and screenshots (if applicable). | ||
| - **Fully complete the bug report form.** [Opening a new issue](https://github.com/ThrowTheSwitch/Ceedling/issues/new/choose) offers a bug report form that requests all the information we need to quickly and efficiently address your issue. Be clear, concise, and descriptive. Provide as much information as you can, including steps to reproduce, stack traces, compiler errors, library versions, OS versions, and screenshots (if applicable). |
There was a problem hiding this comment.
which... concise or descriptive? ;)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
[skip ci]
mvandervoord
left a comment
mvandervoord
left a comment
There was a problem hiding this comment.
I feel like the latest changes strike a perfect balance. Information-gathering and gentle prompts, without slowing down or intimidating a potential poster. Thanks!
Summary
Adds GitHub intake templates and aligns the contributor and release process docs with them. These changes are on top of a basic set of revisions already in place to modernize and correct our contributor policies, etc. These changes in this PR specifically make use of available GitHub features to evolve the project towards common certification standards.
Documentation and GitHub configuration only; no changes to
lib/or tests.GitHub templates (new)
.github/ISSUE_TEMPLATE/bug_report.yml: form requiring Ceedling version, environment, and a dropdown asking whether any C test suite results were wrong (false pass, test not run, bad totals/coverage). Also collects description, config excerpt, and console output..github/ISSUE_TEMPLATE/feature_request.yml: problem / proposed outcome / alternatives..github/ISSUE_TEMPLATE/config.yml: disables blank issues; links to Discourse (questions), private security advisories, and the docs..github/pull_request_template.md: description section plus the PR checklist, including a question on whether a change could make a test falsely pass, not run, or misreport results/coverage.Docs
docs/CONTRIBUTING.md: refers to the new issue forms, adds a "tell us if a test result was wrong" note, and notes the checklist appears in every PR.docs/CeedlingPullRequestChecklist.md: notes it is kept in sync with the PR template.docs/mkdocs/development/releases.md: branch list reformatted; states thatmasterandnext_versionare protected (PR-only, maintainer merge after CI, no direct/force pushes or deletion).Items to review
releases.mdstates a policy. The rulesets are not yet enabled, so enable them before or alongside merge, or soften the wording.CeedlingPullRequestChecklist.mdare meant to match; confirm the template's additions (config defaults/reference, starter project file, compatibility, test-result item) are what you want in both.config.yml.Base:
next_versionbranch.