# Limiting PR creation to “verified” contributors/collaborators

**URL:** <https://forum.djangoproject.com/t/limiting-pr-creation-to-verified-contributors-collaborators/44205>\
**Category:** Django Internals\
**Created:** [February 19, 2026, 6:50am UTC](https://forum.djangoproject.com/t/limiting-pr-creation-to-verified-contributors-collaborators/44205 "2026-02-19T06:50:52Z")\
**Posts on this page:** 1\
**Showing post:** 18

<div class="post-metadata">

**Author:** ![nessita](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/nessita/32/12194_2.png) [@nessita](https://forum.djangoproject.com/u/nessita)\
**Post date:** [April 10, 2026, 12:47pm UTC](https://forum.djangoproject.com/t/limiting-pr-creation-to-verified-contributors-collaborators/44205/18 "2026-04-10T12:47:59Z")

</div>

Hi all, wanted to share a concrete update on the automation front. Building on the work @frankwiles started in his [pr-playground repo](https://github.com/frankwiles/pr-playground#), I have been working on [a PR](https://github.com/django/django/pull/21077) that automatically runs checks and closes PRs that do not meet minimal quality requirements. These are:

- There is a valid Trac ticket linked to the PR
  - A Trac ticket must be referenced via `ticket-NNNNN` (or `N/A` is allowed for trivial changes, where trivial changes are measured by diff length)
  - The ticket must be in `Accepted` stage
  - The ticket must have the `has_patch` flag set
  - The action does polling every 5 seconds up to a minute to wait for the has\_patch flag. We can fine tune these thresholds.

- A real branch description is provided (not the placeholder text)
- The AI disclosure checkbox is filled out (and how the AI tool was used must be explained when AI was used)
- The checklist is completed (for the mandatory checkboxes)

PRs that fail any of these get a comment with exact details about what is missing, how to solve the issues, and then closed. The workflow does not apply equally to everyone: contributors with commits in the past ~3 years get a comment if something is missing but their PR stays open. It is not a manually curated “allowlist”, but the effect is similar: established contributors are not blocked, drive-by submissions are. The “allowlist” is effectively self-maintaining, it derives from git history. We could even have a “3-tier” logic where:

1. No commits, message and PR closed. [current]
2. A commit in the past 3 years, message but no PR closing. [current]
3. More than 5? commits in the past 3? years → no requirements at all, author gets a full pass [very doable]

This proposal is available now, merged, [in my fork](https://github.com/nessita/django/) so you can propose PRs against it and see what happens in various scenarios. It is not a perfect solution, but IMHO it addresses the core problem. Big thanks to Frank who did the core of the implementation 👏 🏆

Happy to answer questions and take feedback!  
Thanks, Natalia.

---

_[View the full topic](https://forum.djangoproject.com/t/limiting-pr-creation-to-verified-contributors-collaborators/44205)._