# Proposed changes to Trac to address problematic contribution patterns - please vote **URL:** \ **Category:** Django Internals\ **Created:** [October 15, 2026, 8:27am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191 "2026-10-15T08:27:16Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![sarahboyce](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/sarahboyce/32/12734_2.png) [@sarahboyce](https://forum.djangoproject.com/u/sarahboyce)\ **Post date:** [October 15, 2026, 8:27am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/1 "2026-10-15T08:27:16Z")
The following changes to Trac have been suggested by members of Django’s Triage and Review team. We would appreciate quick votes (+1, 0, -1) on each proposal. After some discussion, I will create GitHub issues for the proposals the community supports. 1. **Restrict assignment before a ticket is accepted.** 2. **Limit contributors to 3 open, accepted tickets assigned to them at once.** 3. **Add a “Low” severity level.** 4. **Add an “experienced contributor required” flag.** 5. **Restrict changes to the “Triage Stage” to Triage and Review team members.** * * * I am +1 to all proposals 💚 ---
**Author:** ![nanorepublica](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/nanorepublica/32/14211_2.png) [@nanorepublica](https://forum.djangoproject.com/u/nanorepublica)\ **Post date:** [October 15, 2026, 8:46am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/2 "2026-10-15T08:46:31Z")
This all sounds very sensible! +1 to all of them. My only additional suggestion in the point 2 warning message would be to direct folks to the review queue in Trac and perhaps a link to your keynote from Dublin about how to do PR reviews. Although this may be counter productive if these new contributors just produce an AI slop review of code. ---
**Author:** ![villager](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/villager/32/24305_2.png) [@villager](https://forum.djangoproject.com/u/villager)\ **Post date:** [October 15, 2026, 9:39am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/3 "2026-10-15T09:39:38Z")
I’m -1 to proposal 5. **Restrict changes to the “Triage Stage” to Triage and Review team members.** +0/1 to the first four proposals. Is it possible to narrow the change of 5. to restrict ticket reporters from changing the ticket status to “accepted”? Would this still address the concerns from the Triage and Review team? I think it’s really cool that the wider community has the ability to triage tickets. Someone who doesn’t have any status in the community can communicate, “Hey, I think this should be fixed or this belongs in Django.” For me it would be a shame if that wasn’t possible (to this extent) anymore. ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [October 15, 2026, 10:22am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/4 "2026-10-15T10:22:40Z")
+1 to 1, 2, 3, 5 are all various controls that are clear, adjustable and I’m good with implementing them. My main concern is around #4. This is the one that will cause people to self select out and exacerbate our existing issues of imposter syndrome. Depending on how widely we use this, it could have a fairly significant impact on prospective contributors as a whole. I’d like to know more about how 4 would be planned to be used. ---
**Author:** ![Lily-Foote](https://avatars.discourse-cdn.com/v4/letter/l/c37758/32.png) [@Lily-Foote](https://forum.djangoproject.com/u/Lily-Foote)\ **Post date:** [October 15, 2026, 10:56am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/5 "2026-10-15T10:56:43Z")
I’m +1 on 1, 2, 3 and 4. For 5 I wonder if restricting to contributors with a merged PR would be enough? Tim, the idea for 4 is to be able to mark issues that are not suitable for a first or second contribution. Things that we expect to be difficult enough to require someone familiar with the process. ---
**Author:** ![theorangeone](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/theorangeone/32/21264_2.png) [@theorangeone](https://forum.djangoproject.com/u/theorangeone)\ **Post date:** [October 15, 2026, 11:40am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/6 "2026-10-15T11:40:51Z")
1. I’m concerned that people will just comment saying “i’ll work on this” rather than assign. Can we tweak the contributor process to mention that, and possibly the help popup in Trac? Otherwise `+1` from me 2. I like the idea of this, but it has problems. Tickets can often be stuck in Accepted waiting for review, preventing a contributor from picking up new work, despite there being nothing they can do to progress the tickets assigned to them. Should the restriction instead be on 3 assigned tickets with any of the “patch needs X” attributes? As documented, I’d be `-1` 3. Huge `+1` from me. The security team in particular often punt non-security low-severity findings to Trac, so it’d be nice to keep that reflected for people reviewing / triaging tickets. 4. I think I’m `-1` on this. I share Tim’s concerns around imposter syndrome and the self-selecting nature. I’d suggest parking this one pending an outcome on [https://forum.djangoproject.com/t/revive-or-retire-the-django-core-developer-status/45509](https://forum.djangoproject.com/t/revive-or-retire-the-django-core-developer-status/45509) 5. I like this idea, so long as contributors continue to add comments to tickets that they either experience the issue, like an informal acceptance. Although I agree that Triage and Review may be too narrow for this. TLDR: `+1` for 1, 3 and 5. `-1` for 4 and 2. ---
**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:** [October 15, 2026, 11:40am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/7 "2026-10-15T11:40:52Z")
I’m in favor of all the items with the caveat that I think we must have an easy way to lift restrictions when someone meets a given condition. Specifically, I would focus on enforcing these new policies on contributors with N or less commits in the repo (N around 10). Everyone else, no changes. About #4, one minor addition to the proposal: in the meeting we also mentioned that this flag could, perhaps, be better called “bad first issue”, is not necessarily that it needs an experienced contributor. We can iterate on the name but the goal is to steer very new contributors in the right direction. ---
**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:** [October 15, 2026, 11:47am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/8 "2026-10-15T11:47:24Z")
> [@theorangeone](#): > > 1. I like the idea of this, but it has problems. Tickets can often be stuck in Accepted waiting for review, preventing a contributor from picking up new work, despite there being nothing they can do to progress the tickets assigned to them. Should the restriction instead be on 3 assigned tickets with any of the “patch needs X” attributes? As documented, I’d be `-1` The main problem we need to mitigate is contributors opening large numbers of low-quality PRs at once. For contributors who are still learning the process, having several tickets awaiting review may be exactly when it is useful to pause: feedback on those contributions can inform their next work and avoid multiplying the same issues across more PRs. I would therefore keep/rephrase the bullet, but apply it only to a subset of contributors (for example, those with fewer than N merged contributions, as I suggested above). Beyond that threshold, they have demonstrated familiarity with the process and should be able to work on multiple tickets at once. ---
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [October 15, 2026, 12:06pm UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/9 "2026-10-15T12:06:51Z")
I think +1 to all. These are suggestions coming from the T&R team, who are on the front line. Ref 5, arguably T&R only is a little strong. I will still from time to time triage the odd ticket, and locking that down would stop that. The historic _anyone can triage_ should ideally be maintained in spirit, perhaps along the X commits (or something) line that @nessita mentioned. Ref 4, the whole point is that people self-select out, right? The risk is over applying it, for which we have to trust folks to use their judgement. ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [October 15, 2026, 12:11pm UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/10 "2026-10-15T12:11:51Z")
> [@carltongibson](#): > > Ref 4, the whole point is that people self-select out, right? The risk is over applying it, for which we have to trust folks to use their judgement. My interpretation was that it’s there as cover to justify closing PRs on complex areas from unknown people. I’m now seeing points about it being a way to shepherd people to appropriate contribution opportunities. ---
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [October 15, 2026, 12:17pm UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/11 "2026-10-15T12:17:52Z")
Likely it should be both. The probability of an unknown person just turning up and tackling a tough internals issue is vanishingly small. ---
**Author:** ![villager](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/villager/32/24305_2.png) [@villager](https://forum.djangoproject.com/u/villager)\ **Post date:** [October 15, 2026, 12:25pm UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/12 "2026-10-15T12:25:15Z")
> [@theorangeone](#): > > 1. I’m concerned that people will just comment saying “i’ll work on this” rather than assign. Can we tweak the contributor process to mention that, and possibly the help popup in Trac? In the [docs about Triaging Tickets](https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#:~:text=Please%20don%E2%80%99t%20promote%20your%20own%20tickets%20to%20%E2%80%9CAccepted%E2%80%9D) it says this: > - Please **don’t** promote your own tickets to “Accepted”. Another community member should review the report and set this stage after reproducing and confirming the issue. I think a note in Trac would also be helpful. ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [October 15, 2026, 12:27pm UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/13 "2026-10-15T12:27:52Z")
> [@nessita](#): > > About #4, one minor addition to the proposal: in the meeting we also mentioned that this flag could, perhaps, be better called “bad first issue”, is not necessarily that it needs an experienced contributor. We can iterate on the name but the goal is to steer very new contributors in the right direction. Did the team discuss a complexity indicator to go along side the severity? That would side step the trouble of naming a gatekeeping flag. ---
**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:** [October 15, 2026, 1:01pm UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/14 "2026-10-15T13:01:36Z")
> [@CodenameTim](#): > > Did the team discuss a complexity indicator to go along side the severity? Almost! I mentioned my concerns with the “easy pickings” flag being useless, and repeated my [proposal](https://forum.djangoproject.com/t/upcoming-newcomer-sprints/46026/3) about a flag for “mentoring opportunity” instead. A relative beginner could be involved in tickets marked as such, as long as a mentor was in the loop early enough and had the opportunity to scaffold any prerequisite tickets. When self-assigning a “mentoring opportunity” ticket, someone monitoring Trac activity (me) could ask, “who is your mentor?” and deassign if not answered. The idea being that for these tickets a relative beginner is welcome but should not present a finished product at the start. I think I like that better than a straight “complexity indicator”, but we didn’t evaluate this much nuance on the call. > [@CodenameTim](#): > > I’m now seeing points about it being a way to shepherd people to appropriate contribution opportunities. This was the intent, I think – naming is hard! > [@villager](#): > > I think it’s really cool that the wider community has the ability to triage tickets. Someone who doesn’t have any status in the community can communicate, “Hey, I think this should be fixed or this belongs in Django.” For me it would be a shame if that wasn’t possible (to this extent) anymore. In spirit I agree – historically open triage has been a huge benefit for Django, and honestly I don’t think I would have become involved in the community otherwise. I’d prefer to see a more granular anti-poaching policy, like “don’t accept a ticket and set yourself to the owner immediately” where the “waiting period” could scale with the number of commits. Someone with 0 commits needs to wait six weeks before poaching a ticket they accepted themselves (“insincere triage”) etc. Someone with 1 commit waits two; 2 commits, no waiting period etc. If we have trouble with too many “LGTM” reviews setting Ready for Checkin let’s just re-evaluate when that happens. My votes: 1 - **Restrict assignment before a ticket is accepted.** +1 2 - **Limit contributors to 3 open, accepted tickets assigned to them at once.** +1 3 - **Add a “Low” severity level.** + 1 4 - **Add an “experienced contributor required” flag.** +1 with caveats, naming problem 5 - **Restrict changes to the “Triage Stage” to Triage and Review team members.** -1 as described, +1 if we do a more targeted no-poaching policy > [@theorangeone](#): > > 1. Tickets can often be stuck in Accepted waiting for review, preventing a contributor from picking up new work, despite there being nothing they can do to progress the tickets assigned to them. I disagree that there’s nothing they can do – they can get a colleague to review their work and mark it ready for checkin, which floats to the top of the merger’s priority list (just below release blockers & security). They can arrange a review swap with another contributor, which we explicitly suggest on the forum threads announcing upcoming feature freezes. If you have 3 tickets “stuck” I don’t think it helps anyone to have 13 tickets “stuck”. ---
**Author:** ![vishy0](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/vishy0/32/33219_2.png) [@vishy0](https://forum.djangoproject.com/u/vishy0)\ **Post date:** [October 15, 2026, 4:41pm UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/15 "2026-10-15T16:41:44Z")
I vote +1 to all. Would #1 be of any help, to unaccepted tickets with open PR. There are often tickets, with an attached PR, prior triage. If such pull requests are not welcome, I wonder a checklist entry would help on PR description. Something like, “This ticket has been reviewed and accepted.” ---
**Author:** ![villager](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/villager/32/24305_2.png) [@villager](https://forum.djangoproject.com/u/villager)\ **Post date:** [October 16, 2026, 12:10am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/16 "2026-10-16T00:10:27Z")
I believe the automated check in GitHub already addresses PRs opened for tickets that are not ready to accept PRs. [django/scripts/pr\_quality/check\_pr.py at main · django/django · GitHub](https://github.com/django/django/blob/main/scripts%2Fpr_quality%2Fcheck_pr.py#L243) I think proposal #1 mostly would help to discourage activity on tickets not ready for PRs. And also have the benefit of allowing the reporter a moment to take ownership themselves. ---
**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:** [October 16, 2026, 11:54am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/17 "2026-10-16T11:54:14Z")
+1 on 1, 2, 3 and 4. For 5, -1. As presented, it seems too restrictive. Could we: 5. Anyone can update Triage Stage except reporter and current (latest?) owner And then: 1a. A ticket cannot be assigned to anyone at all while its Triage Stage is Unreviewed (not 100% necessary though hear me out) 1b. Cooling off period before taking ownership of something you triaged per Jacob’s suggestion For the report+want to work on it group, not allowing pre-triage assignment might seem mean. However, it’s easily addressed by a comment “Have reported this and would like to work on it if accepted” which can be respected by the triager. Overall that seems more in the spirit of the triage decision focusing on the merits of the report. And everyone taking a more sedate approach to ownership sets an example of calmly working through a process, rather than new contributors feeling they are in a race to get a PR open. ---
**Author:** ![Pravin](https://avatars.discourse-cdn.com/v4/letter/p/b38774/32.png) [@Pravin](https://forum.djangoproject.com/u/Pravin)\ **Post date:** [October 16, 2026, 2:32pm UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/18 "2026-10-16T14:32:25Z")
I’m +1 to all. In my POV, Proposal 1 would be ineffective without Proposal 5. ---
**Author:** ![vishy0](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/vishy0/32/33219_2.png) [@vishy0](https://forum.djangoproject.com/u/vishy0)\ **Post date:** [October 17, 2026, 4:09am UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/19 "2026-10-17T04:09:54Z")
> I believe the automated check in GitHub already addresses PRs opened for tickets that are not ready to accept PRs. [django/scripts/pr\_quality/check\_pr.py at main · django/django · GitHub](https://github.com/django/django/blob/main/scripts%2Fpr_quality%2Fcheck_pr.py#L243) > > I think proposal #1 mostly would help to discourage activity on tickets not ready for PRs. And also have the benefit of allowing the reporter a moment to take ownership themselves. Yes—that flag helps flag issues once the PR is open, but it only gives notice afterward. I often see, eagerly opened LLM generated PR and it has to be closed. Prior ticket ownership, work is already being submitted. I thought, this could be a minor heads up. ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [October 19, 2026, 2:16pm UTC](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191/20 "2026-10-19T14:16:53Z")
> [@smallsaucepan](#): > > For 5, -1. As presented, it seems too restrictive Do you mind sharing which scenario(s) are being restricted that you think would be going too far? * * * Edit: Regarding 4, I could live with it. I’m going to be really unhappy with it though, especially if it’s named as something obviously gatekeep-y as “experienced contributor required”. If that name/process can be massaged into something a bit more welcoming/open, I’d be in active support of it like the others. [Next page](https://forum.djangoproject.com/t/proposed-changes-to-trac-to-address-problematic-contribution-patterns-please-vote/46191.md?page=2)