Very good points Shahar. > - 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.
I think this should be on a case-by-case basis. We are unlikely to work out all possible edge cases, and (luckily) we are humans that can talk about it in reviews and decide what to do. We should mention - in the contributing docs - that those kind of situations might happen and that in such case we will use the usual - attempt to arrive at consensus - approach. Eventually, the committer might decide what to do (and nothing new here, committers have the rights to individually veto ANY code change anyway) - by having "request changes" or closing a PR. I would not do any automation here - all that I described above is low-tech, no-automation, mainly updating our contributing docs and education of people by explaining them when they go outside of the agreed process. - 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 I think it's up to the maintainer / triager doing the assignment to decide. And it is not really gating - it's just "not assigning". People can still contribute, can comment "I work on it" - nothing changes, except that we won't assign them which will help people to search for issues that are not assigned - but them leave it to them to judge if others are working on it. I think on the contrary having too many assignments now by people who are not following those is exactly "gating" - because it is a signal that someone is "owning" solving the issue. In a way - if people start just commenting "I am working on it" is becoming a "soft" assignment as well, but it is not-gating and naturally decays over time (by the time it was commented on). Assignment has no decaying property, unfortunately. Would that alleviate the concerns? I think we have self-decaying comments as a replacement of assignment, we leave a lot of judgment to contributors (which I think is very important to not make decisions for them) and I think it's actually fixing the current "accidental gating" - without having to do any automation at all - just changing our processes and behaviours of those who are triaging and responding to issues (which as you mentioned is unfortunately a rather small group even within the committer group). I think those changes in the process will decrease the energy and effort needed by maintainers for such triage and review of issues, so it's possibly a way to make people more inclined to do it - which might somewhat respond to your concerns about triaging things (which I share). J. On Mon, Feb 16, 2026 at 5:13 PM Shahar Epstein <[email protected]> wrote: > 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, > > >
