I’d like to suggest allowing low-risk pull requests — such as typo fixes, small documentation changes, and test additions — to proceed without a Trac ticket.
Django’s workflow expects a ticket reference for every PR, which makes sense for features and bug fixes. But in practice, people often use “no ticket” to indicate that a PR doesn’t require one.
Looking at merged PRs, this isn’t rare — it’s a consistent pattern. Most of these cases involve documentation changes, tests, typo fixes, or small cleanups. In these situations, creating a ticket tends to add more overhead than value.
Rather than relying on the implicit convention of “no ticket”, it might make sense to acknowledge this more explicitly.
The types of changes I have in mind are:
documentation-only changes
typo or wording fixes
test additions or fixes without behavior changes
small cleanups or refactors
CI or build configuration updates
localization updates
This isn’t about bypassing review, but making it easier for maintainers to quickly understand and distinguish these changes.
For consistency, we could also define a simple PR title convention in the contribution guidelines (e.g. “Fix typo”, “Update docs”, “Add test”), and validate it via CI with automatic labeling. (This is also quite relevant in the context of LLM usage.)
For reference, I also put together a repository with the related data and analysis:
The statistics above are based on collecting and analyzing all relevant merged PRs.
So, is the idea to distinguish “no ticket, and that’s okay” from “no ticket, please fix”? In my experience the “please fix” comes from a human noticing that something is wrong, either the author fixing a ticket realizing they haven’t mentioned the ticket anywhere, or a reviewer telling the author to open a ticket.
This also connects pretty directly to what’s being built in pr-playground. As you mentioned in the other thread, it’s still in a “trial in a separate repo” stage, and the current check_pr.py setup requires a ticket reference for every PR and auto-closes anything without one. Right now the only exception is docs-only changes.
You could try to add path-based exemptions for each category, but that seems like it would get messy pretty quickly. Docs are easy since they live under a clear directory, but things like tests, typo fixes in code, or CI changes don’t really have that kind of structure. At some point the automation is just guessing intent from file paths.
And that’s kind of the core issue — “no ticket” is ambiguous. It can mean “this doesn’t need a ticket” or “I forgot to reference one,” and automation can’t reliably tell the difference.
I definitely agree that human review is still where the actual decision should happen. This isn’t about replacing that, just about making the author’s intent clearer before it gets there, so both automation and reviewers have a bit more context.
Since the workflow is still in a trial phase, it felt like a reasonable time to explore something like:
has a ticket reference → normal flow
has a minor tag → intentionally ticketless, reviewer decides
neither → safe to auto-close
That way we don’t need to keep adding more and more heuristics, and the overall logic stays pretty simple.
The vast majority of these ticketless merges are from prolific Django contributors. I think it would make more sense to just exempt a certain set of users from the PR auto-close flow entirely as they will VERY likely either 1) Have a ticket and well written PR description when appropriate 2) know when it’s fine to just have a low effort PR
The thing is, there are 721 unique authors in the dataset, and 624 of them only have 1–2 ticketless PRs each — that’s 715 PRs, about 23% of the total.
Most of these are first-time contributors making small changes like fixing typos or cleaning up docs, so they’d never be on an exemption list.
These are usually the easiest PRs to review, and also where a good first experience matters most.
Auto-closing them just because the author isn’t recognized yet feels like it’d do more harm than good.
User-based exemptions make sense for known contributors.
A minor tag can cover everyone else.
It looks like the PR validator you have built does allow PRs to pass without a Trac ticket mentioned, provided the rest of the PR checklist was filled out. If that’s the case, I’m not sure we need another label here to avoid something being autoclosed.
Does GitHub support allowing a PR to be created by the public with a subset of labels? For some reason I thought we had to make all labels available and/or the user needs triage permissions on the repo.
If not, we could potentially have them write in the ticket area “N/A - typo”
That’s an explicit “intentionally ticketless” without requiring tagging.
Writing “N/A - {reason}” in the PR ticket number section is usable by all contributors: first-time or prolific, whether or not they have GitHub triager permission. (I suppose it might get misused, but it seems like slop PRs tend to ignore the instructions entirely, not try to find loopholes in them.)
Then the validator can check there’s either a ticket number or declared reason a ticket isn’t needed. (There might eventually be additional validation for certain reasons: e.g., “N/A - docs” changes should be entirely in the docs dir. “N/A - typo” should be a line or two max, modulo reformatting. But that could come later, only if needed.)
I’d prefer this over using GitHub labels, especially bot-automated labels on valid PRs. (The CPython repo is a cacophony of jabbering bots constantly adding and removing labels and chiming in with comments. Action-required updates get lost among informational and automation-support ones. As an only-occasional contributor there I find the whole thing noisy and difficult to follow. I wouldn’t want Django to become that.)
I hadn’t considered that approach, but it makes a lot of sense. I also agree that increasing the number of bots could make the review process more noisy and harder to follow, which is something I’d prefer to avoid.
Standardizing the use of the ticket field (e.g. “N/A - {reason}”) seems like a simple and effective solution.
Thanks again for sharing this idea — I really appreciate it.
That’s an explicit “intentionally ticketless” without requiring tagging.