# Contradictory Trac instructions on when to set "Has patch" **URL:** \ **Category:** Django Internals\ **Created:** [July 13, 2026, 3:20am UTC](https://forum.djangoproject.com/t/contradictory-trac-instructions-on-when-to-set-has-patch/45465 "2026-07-13T03:20:52Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![smallsaucepan](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/smallsaucepan/32/31265_2.png) [@smallsaucepan](https://forum.djangoproject.com/u/smallsaucepan)\ **Post date:** [July 13, 2026, 3:20am UTC](https://forum.djangoproject.com/t/contradictory-trac-instructions-on-when-to-set-has-patch/45465/1 "2026-07-13T03:20:52Z")
When contributing a new patch (as a PR) the instructions on the Trac ticket are (bold mine): > Check the “Has patch” flag on the ticket **after sending a pull request** and include a link to the pull request in the ticket comment when making that update. The usual format is … Trac is saying to create the PR first and then set the Trac flag. In my experience though this immediately causes a warning comment on the PR: > ⚠ **Warning: Incorrect Trac Ticket Flag** At the time of making my first contribution this seemed at odds with the PR checklist template - “I have checked the “Has patch” ticket flag in the Trac system”. I took a punt on the day and got it wrong, so suspect this is catching out other new contributors as well. Not sure there is any way to change the mechanics of the PR check to allow a grace period, so can we update the Trac instructions instead? > Set the “Has patch” flag on the ticket before sending the pull request. Once sent update the Trac comment with a link to your new pull request. The usual format is … ---
**Author:** ![StephanieAG](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/stephanieag/32/17567_2.png) [@StephanieAG](https://forum.djangoproject.com/u/StephanieAG)\ **Post date:** [July 14, 2026, 12:57pm UTC](https://forum.djangoproject.com/t/contradictory-trac-instructions-on-when-to-set-has-patch/45465/2 "2026-07-14T12:57:42Z")
> [@smallsaucepan](#): > > catching out other new contributors as well I got tripped up with the same thing too - #11 in my [messy public notes on the first contribution instructions](https://forum.djangoproject.com/t/public-notes-on-first-contribution-instructions-maybe-ideas-for-some-new-contributor-opportunities/45374) ---
**Author:** ![smallsaucepan](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/smallsaucepan/32/31265_2.png) [@smallsaucepan](https://forum.djangoproject.com/u/smallsaucepan)\ **Post date:** [July 14, 2026, 11:58pm UTC](https://forum.djangoproject.com/t/contradictory-trac-instructions-on-when-to-set-has-patch/45465/3 "2026-07-14T23:58:34Z")
Great write up @StephanieAG. Any improvements to suggest for the new wording? For comparison: > Set the “Has patch” flag on the ticket before sending the pull request. Once sent, Edit your “Has patch” comment in Trac to include a link to the new pull request. The usual format is … Using “Edit” to match the UI and more clearly guiding the user to update their comment rather than create an additional one. Ends up looking something like this: [#17752 (Serialization and multi-table inheritance) – Django](https://code.djangoproject.com/ticket/17752#comment:9) Better to less specific / potentially brittle? ---
**Author:** ![medmunds](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/medmunds/32/22140_2.png) [@medmunds](https://forum.djangoproject.com/u/medmunds)\ **Post date:** [July 17, 2026, 10:34pm UTC](https://forum.djangoproject.com/t/contradictory-trac-instructions-on-when-to-set-has-patch/45465/4 "2026-07-17T22:34:13Z")
> [@smallsaucepan](#): > > Not sure there is any way to change the mechanics of the PR check to allow a grace period […] This would be my strong preference if possible. I worry that—in our attempt to thwart AI sloppers and stat gamers—we’re making things too complex for genuinely well-intentioned new contributors. Instantly closing a PR on a correctable technicality like “didn’t check has-patch yet” seems aggressive.\[1\] Particularly if the opposite order seems to make more sense to you (✋). We might borrow some ideas from CPython. Rather than closing PRs immediately, their gang of bots notes any problems and _waits to apply_ the “ready for review” label until they are fixed. Reviewers ignore PRs that aren’t marked ready. (I’m not sure if they’ve automated closing PRs that don’t get corrected, but that’s an entirely reasonable use for a stalebot: our review bot made a specific request, N days have elapsed without it being addressed, _now_ we’re closing the PR.) * * * 1. I’m on a bit of a crusade against automated processes that exhibit a “[computer says no](https://en.wiktionary.org/wiki/computer_says_no)” attitude. Even more so of late: we need to model the behavior we’d want from our future AI ~~overlords~~ benefactors, now, while they’re still willing to learn from us. 🫤 ---
**Author:** ![blighj](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/blighj/32/29054_2.png) [@blighj](https://forum.djangoproject.com/u/blighj)\ **Post date:** [July 28, 2026, 5:49am UTC](https://forum.djangoproject.com/t/contradictory-trac-instructions-on-when-to-set-has-patch/45465/5 "2026-07-28T05:49:46Z")
Another potential negative experience is tickets getting auto closed after the review process is started. Here is an example I was reviewing for a new contributor, [PR #20689](https://github.com/django/django/pull/20689/), they were updating the description after addressing feedback and caused the AI checkbox to be misformated and the bot picked this up and closed the ticket. I’m not saying it is a disaster, I’ve been able to reopen the ticket for them, but it doesn’t feel welcoming to me. ---
**Author:** ![Louis2608](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/louis2608/32/33307_2.png) [@Louis2608](https://forum.djangoproject.com/u/Louis2608)\ **Post date:** [September 10, 2026, 9:33am UTC](https://forum.djangoproject.com/t/contradictory-trac-instructions-on-when-to-set-has-patch/45465/6 "2026-09-10T09:33:24Z")
You’re 100% right, this trips up almost every first-time contributor! That bot check runs literally the second the PR is opened, so if the Trac flag isn’t flipped beforehand, it flags it immediately. Updating the Trac documentation wording to match the actual workflow just makes total sense. You should definitely open a Meta ticket on Trac or start a quick thread in the Django Forum’s “Mentorship & Governance” / “Django Internals” category. I’m sure the core devs would be happy to merge a doc tweak that saves new contributors from that instant bot confusion. ---
**Author:** ![jacobtylerwalls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/jacobtylerwalls/32/30603_2.png) [@jacobtylerwalls](https://forum.djangoproject.com/u/jacobtylerwalls)\ **Post date:** [September 17, 2026, 12:26am UTC](https://forum.djangoproject.com/t/contradictory-trac-instructions-on-when-to-set-has-patch/45465/7 "2026-09-17T00:26:19Z")
This came up at the DjangoCon US sprints, and everyone I spoke with there was in favor of adding some sort of “wait” period, so I’m hopeful we remedy that soon.