Thanks for bringing this topic up - I wanted to do this for a while :) First, disclaimer: recently I've been quite active around the GitHub issues area: labeled, assigned, unanssigned, closed, reopened, etc.
I think that the proposal in its current form needs refinement: - Assuming that the contributor is known and suitable for assignment - what will be the actual meaning of "being assigned" to an issue from a commiter's perspective? If A is assigned to an issue, and B creates a PR for it while A is being assigned (itentionally or not)- should committers (/automation?) close B's PR as the issue is already assigned? It might be trivial, but currently implicit from the current description. - What are the criteria for "knowing the person"? Not all contributors are active on dev thread/Slack, some of them are just anonymous human GitHub users (like I was before my first PR on Airflow). I think that "gatekeeping" the assignment, while it may discourage uncontrolled AI users - it will just defer the "dog fight" from the GitHub issue section into the PRs (i.e, instead of choosing which contributor to assign to an issue - I'll have to arbitrarily pick which PR to merge). I think that the solution should be somewhere along the lines of: 1. Limiting number of open issues assigned per new(/any?) contributors 1a. If a triager/maintainer suspects of uncontrolled AI usage by a requester, they may reject their request on the spot. 2. Automating unassignment after certain time of inactivity (+reducing current definiton of inacitvity from 2 weeks to one) 3. Creating a short etiquette for issues assignment targeted at the contributors (hopefully both human and non-human contributors will respect it...). Not the main topic of this thread, but somewhat related - I think that we need more involement of both maintainers and triagers in the GitHub issues area. We have about 1400 issues, 250 untriaged, and every time I try to triage 20 of them - new 20 pop up. Not directed at someone specific, but I think it will really help the community if you could lend a hand :) Shahar On Mon, Feb 16, 2026, 16:12 Jarek Potiuk <[email protected]> wrote: > Hello here, > > After disconnecting a bit working on the 2.11.1 release (glad it's about to > be released finally) I caught up with some recent issues and I think the > "assign" feature gets somewhat abused. > > There are a number of issues where new contributors ask to be assigned and > they either don't work on or what they submit is mostly AI slop. > > I think one of the reasons for that is "Assigning" might be seen by some > people as a sign of trust and maybe they somehow bust their reputation by > having issues assigned to them. > > Now, I think our "assignment" was always a bit broken - when issues had > people assigned, it kinda blocked others from working on them - I've seen > quite a few comments from people "I would like to work on some issue but > there was someone already assigned". We did not actively clean the people > who did not complete their "assignments" (and we do not want to spend time > on it either) - and some of the old issues that have people assigned are > simply not touched by new contributors. > > Assignment has two roles - one is to maybe allow people to see issues they > are assigned to, and two - it's a kind of lock preventing more than one > person from working on the same issue. Some people in the past complained > that they were assigned - but someone else got a PR - so this is also how > some people understand it. > > With the current AI-slop era and people signing up for many things they > often have no idea how to do - trusting that agents will do it for them, I > think the 2nd role is quite broken. While in essence it was supposed to > prevent two people working on the same thing, right now it might prevent > people who know what they are doing to work on those issues. > > *Proposal:* > > I think we can "unbreak it" by changing a bit what "assignment" is and > adapting our process. > > I believe we should start treating assignment as: > > ** "I know the person and I trust they will get it done or unassign > themselves if they can't complete"* > > I think we should: > > - only assign issues to committers/trusted contributors who we trust > will work on the issue and lead to completion, and that they un-assign > themselves if they see they cannot complete it. We will actually expect > people to do this un-assignment in case they want to "free" the issue. > > > - stop assigning unknown people when they ask and strongly *DISCOURAGE* > them > from asking "can I take the issue". We should add in our contributing > docs > and repeat it if people do not read it that we are not assigning issues > to > new contributors and they should just open PRs if they want to work on > something without asking - this will hopefully cut a lot of noise from > issue comments > > > - describe that it is absolutely ok if an issue is not assigned and > several people work on it - whoever gets good green, reviewed PR will > win, > others might also help to review other's PRs on the same issues if they > see > other PRs are better. > > > I think that will help a bit with issues being effectively blocked by > people (or bots) who do not work on them, and cut the noise a bit on > "asking" or "taking" issues - especially if we keep on reminding it to > people; > > I am happy to do initial unassignment of current issues and to make a PR > proposal for our contribution guide update. > > Let me know what you think - any comments are welcome as usual. > > J, >
