> However, I would also throw a third vote in for keeping assignment but then using an automatic unassignment after some period of time. I think the "soft assignments", having them decay over time (I think people will never really be sure it's decayed enough and it will still effectively gate people fro taking the task) and only assigning to approved folks (see previous comments from others) are all blurry and based on good intentions, which are never as good as mechanisms/automation.
I am not sure what kind of need it would serve to be honest. We would have to make a judgment call that 5 or 10 or 15 (or whatever) days is "enough" to unassign things, which in many cases would be wrong. There are many people that we **want** to assign people to, while we know things cannot be completed in a reasonable time. There are many examples in our "CI/Dev env" project - where trusted people are assigned to issues that are waiting for external work to be done. And it's a clear signal, that the issue is being taken care of **still**. And there are likely many issues in other parts - SQLA2 migration for example, or a number of AIPs we are implementing - often span longer times, and often have external dependencies. Also I think this is actually a very deliberate thing to ask people to make the right judgment in the absence of "clear" 0/1 rules. This is what happens in so called "real life" - including "real contributions". Rarely people get very clear "0/1" signals whether they should do something or not. And if they do - they are really not making any decision, they just follow the decision made for them. If someone has difficulties with making the right judgment in absence of clear rules - they are likely not a very good candidate for contributor. I think - and I am about to call for a consensus (with some concrete proposal of changes to our guidelines) unless I hear otherwise - that this kind of unassignment "logic" would have to be rather complex and brittle to reflect what we would like to achieve - i.e. actually decay the "assignment" over time. I personally prefer 5 people doing 5 implementations at the same time (even if the comments should largely prevent that) and choose the best of those, rather than someone turning their attention elsewhere - because the issue they seem to like most is already "taken" by someone else. Especially when we make it clear that this is both fine, and good learning opportunity if several people work on the same things in parallel). J. On Tue, Feb 17, 2026 at 9:35 PM Oliveira, Niko <[email protected]> wrote: > Firstly, I love this initiative, thanks for bringing it up Jarek. I also > notice and get frustrated by folks "camping" on tasks and never completing > them. > > However, I would also throw a third vote in for keeping assignment but > then using an automatic unassignment after some period of time. I think the > "soft assignments", having them decay over time (I think people will never > really be sure it's decayed enough and it will still effectively gate > people fro taking the task) and only assigning to approved folks (see > previous comments from others) are all blurry and based on good intentions, > which are never as good as mechanisms/automation. > > Cheers, > Niko > > ________________________________ > From: vaquar khan <[email protected]> > Sent: Monday, February 16, 2026 9:09:37 PM > To: [email protected] > Subject: RE: [EXT] [DISCUSS] Stop assigning unknown contributors to issues > (AI-slop prevention) > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. > Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez > pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que > le contenu ne présente aucun risque. > > > > 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/ > <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, > > > > > > > > > > > > > > >
