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.
Restrict assignment before a ticket is accepted.
Before a ticket is accepted, only its reporter would be able to assign themselves to it. This would give triagers time to assess reports before other contributors begin work.
Limit contributors to 3 open, accepted tickets assigned to them at once.
Users with the supertriagers permission would be exempt (such as Triage and Review team members). We would also exempt shared or placeholder owners such as “Django Sprints” and “nobody”.
The aim is to encourage contributors to finish or release existing assignments before taking on more work. When someone who has reached this limit tries to assign themselves to another ticket, they would see a warning message and be unable to do so. We may also unassign some tickets from contributors who are already well above the limit (there are currently 5 people with 10+ tickets assigned).
Add a “Low” severity level.
This would identify issues that should receive less reviewer time and attention relative to other tickets, helping reviewers prioritise their work.
Add an “experienced contributor required” flag.
This would identify tickets that need substantial familiarity with Django’s internals. If a new contributor takes on a flagged ticket, we could close their PR and direct them towards more suitable work without extensive discussion. The aim is to reduce review work from AI-driven contributions on particularly challenging topics.
Restrict changes to the “Triage Stage” to Triage and Review team members.
This would prevent new contributors from accepting tickets themselves to bypass the assignment restriction in proposal 1.
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.
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.
+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.
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.
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
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
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.
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.
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.
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.
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.
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.
Almost! I mentioned my concerns with the “easy pickings” flag being useless, and repeated my proposal 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.
This was the intent, I think – naming is hard!
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
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”.
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.
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.
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.
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.
