Hi Jarek, Shahar, and team, This is definitely the right time for this move. We’ve all seen issues get "reserved" by someone just to have their name on it, only for the work to never actually happen. It blocks everyone else and just kills the project's momentum. Switching to a "submit-to-claim" model is the right call.
To help with the extra PR noise this might create, I’ve been prototyping a validation utility to act as a first line of defense. The goal is to catch the "junk" before a human reviewer ever has to context-switch. It basically runs three quick checks: 1.Substance: It filters out boilerplate or empty scaffolding that doesn't have real logic. 2.Architecture: It catches submissions that "hallucinate" methods or imports that don't exist in our codebase. 3.Basic Robustness: It runs automated stress tests on edge cases. If it fails a simple boundary condition, we know it’s not ready for review yet. If we move to this PR-first policy, we could just plug this into the CI pipeline to keep the signal-to-noise ratio high. Happy to demo how it handled a few recent PRs if you're interested. Regards, Vaquar Khan *Linkedin *-https://www.linkedin.com/in/vaquar-khan-b695577/ *Book *- https://us.amazon.com/stores/Vaquar-Khan/author/B0DMJCG9W6?ref=ap_rdr&shoppingPortalEnabled=true *GitBook*-https://vaquarkhan.github.io/microservices-recipes-a-free-gitbook/ *Stack *-https://stackoverflow.com/users/4812170/vaquar-khan *github*-https://github.com/vaquarkhan On Mon, Feb 16, 2026 at 2:05 PM Shahar Epstein <[email protected]> wrote: > Thanks for commenting and addressing the concerns - I don't mind giving it > a shot and see if it works better for us. > > > Shahar > > > On Mon, Feb 16, 2026, 20:04 Jarek Potiuk <[email protected]> wrote: > > > 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, > > > > > > > > > >
