Why Do Half Your GitHub Issue Reports Skip the Template?
Because nothing in GitHub actually stops a reporter from filing a blank issue. Issue templates are a UI nudge, not an enforced form: a repo can set blank_issues_enabled: false in its template config, and GitHub's own docs confirm that users with write access or above still see a "Blank issue" option in the chooser, labeled "Maintainers only." Outside contributors get filtered into templates, but the block only ever applied to non-maintainers, and it has to be configured correctly to work at all.
That second part is where most of the gap comes from. A community thread on GitHub's own discussion board reports the config being ignored entirely: a repo's config.yml disables blank issues, and non-maintainers can still open one anyway. When the enforcement mechanism itself has an open bug report against it, "half your issues skip the template" stops being a training problem and starts being a platform one.
What's actually causing the split
Three separate things get lumped together as "people don't fill out the template," and they need different fixes.
Blank issues are load-bearing for maintainers, and that door doesn't fully close. The maintainers-only carve-out is intentional, not a bug, for the write-access case, so no config change removes it. If your triage team also has write access and files unstructured issues as shorthand, those show up in the same "skipped template" count as reporter-filed ones.
GitHub Issue Forms (the YAML kind, not markdown templates) change compliance, not just formatting. An empirical study of issue templates across 100 large-scale GitHub projects, covering roughly 350 templates and 1.9 million issues, found that projects using templates saw issue resolution time drop sharply, from 381 days to about 103 days in the sample, and that YAML-based issue forms outperformed plain markdown templates on both resolution time and reopen rate. A markdown template is a wall of text a reporter has to read and voluntarily follow; a YAML form has required fields that block submission until they're filled. If your repo is still on the markdown kind, a chunk of your "skip rate" is a format problem, not a discipline problem.
Template count itself works against compliance. A separate community discussion asks GitHub to let templates be scoped by role, specifically because teams that lean on GitHub Issues for both internal work and public bug reports end up with ten or more templates in one chooser. A reporter facing that list, with no way to tell which one applies to them, is a reporter who picks "Open a blank issue" instead of reading ten titles.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWendell Okonjo's ten-minute audit
Wendell Okonjo has maintained Paperlane's CLI for two years now. The team is six people, their local dev proxy has a few hundred paying teams running it daily, and Wendell had assumed the "half the issues skip the template" number people threw around online was an exaggeration, until he actually pulled the last 60 issues on the repo and counted.
Wendell, in the team's internal Slack: Just went through the last 60 issues by hand. 34 came in through the bug report form. The other 26 are one-liners, "proxy hangs on restart," no version, no OS, no logs. Eleven of those 26 are from three different people, but I only just noticed because I read them back to back.
Reply from a teammate: Are they using the blank issue link or is the chooser broken?
Wendell: Checked. We're not even on YAML forms, it's still the old markdown template. And I have write access so half my own issues are blank ones I typed from my phone.
The fix he shipped wasn't a policy memo. He converted the markdown template to a YAML issue form with three required fields (repro steps, version, OS), which meant a submission couldn't go through empty. Two weeks later the blank-issue rate on external reports had dropped, but his own maintainer-filed issues hadn't moved, because the write-access carve-out doesn't apply the form requirement to him. That's the part no template config fixes.
What a required-fields form still won't catch
A required-fields form fixes intake, not the pattern-matching after intake. Wendell still had eleven reports of the same restart bug spread across three people, filed on three different days, in three different phrasings, and the only reason he caught it was a manual read-through he doesn't have time to repeat every week. A form makes each individual report more complete; it does nothing to tell you that three complete reports are the same bug from three different customers.
That's also where "half the issues skip the template" stops being the interesting question. Even at 100% form compliance, unstructured reports keep arriving somewhere else, a Slack DM, a support email, a comment on a closed issue, that never touches GitHub's chooser at all. A required field can't parse a sentence someone typed in Slack.
This is the point where we'd bring up Modem. We don't ask reporters to fill out anything differently. Modem reads whatever text actually shows up, whether it's a filled-out GitHub Issue Form, a one-line blank issue, or a customer typing in Slack or a support ticket, and pulls out the who, what, and why regardless of the shape it arrived in. When the same bug shows up more than once, Modem counts it as one thing and keeps a running list of who reported it, so Wendell's eleven scattered mentions of the restart hang would have surfaced as a single tracked item on the day the second report came in, not the day he happened to reread the backlog. Modem connects to GitHub alongside the other channels bugs actually get reported in, and the dedupe and requester-tracking work the same whether the source issue used the template or not.
For the piece that stays inside GitHub, a well-built form is still worth having. Structured intake plus a required-fields form is a real improvement over a free-text box, and the study above backs that with resolution-time numbers, not just intuition. The point where it stops being enough is duplicate detection and cross-channel matching, which is a different job than getting one report filled out correctly.
Three changes for your repo, not your reporters
Convert your bug report template to a YAML issue form if it isn't already, with two or three required fields (repro steps, version, environment) that block submission when empty. Check whether blank_issues_enabled: false is actually set in your config.yml, since the docs are specific that it changes contributor behavior but never removes the maintainer-only blank option. If your chooser has more than five or six templates, cut it down or split internal work-item templates into a separate config that public reporters never see.
None of that closes the gap to zero, because a form only governs what happens inside GitHub's own issue chooser. The reports that arrive as a Slack message or a support ticket never see the form at all, and that's the boundary worth knowing before you spend more time tuning the template. For the mechanics of what happens after an issue is filed, see how to triage GitHub issues at scale and whether GitHub can detect duplicate issues before they pile up.
