Yes. This was only about not assigning people. I will propose a PR describing it and ask for consensus.
On Tue, Feb 24, 2026 at 3:22 PM Wei Lee <[email protected]> wrote: > Contributors don’t need to be assigned to do something. Just create a > proper PR directly. > > Best, > Wei > > On Tue, Feb 24, 2026 at 9:07 PM <[email protected]> wrote: > > > As someone who is looking to contribute, I am not clear on the > > requirements for new contributors. Do I need to know someone who is > already > > contributing to even start contributing? That seems to be a barrier that > > would discourage most. Is there a way that atleast the good first issue > > tagged issues can be excluded from this pre condition? > > > > Best regards, > > Sagnik Saha > > > > > On Feb 24, 2026, at 3:59 PM, Wei Lee <[email protected]> wrote: > > > > > > I don't think we necessarily need the unassign tool. We can reconsider > > it if we find that we are still assigning too many people. > > > > > > I like the idea of not assigning an issue to someone until we are > > confident we can trust them. Contributors are welcome to take on any > > issues, even if they are assigned to someone else, as long as they > believe > > they can have their pull requests merged first. Even if their PRs are > > closed afterward, the development experience can still serve as a > valuable > > learning opportunity. This approach allows mentors to conserve mental > > energy when explaining to mentees which issues to take during development > > sprints at Python conferences or community events. Contributors can > choose > > any valid issue they want, as long as they believe they can complete it. > > There should be a limited number of issues already assigned to trusted > > contributors, mostly committers and committers-to-be. > > > > > >> On 2026/02/19 18:36:38 Daniel Standish via dev wrote: > > >> To me "known" means known to *you* (the assigner) -- you know they are > > real > > >> person who does decent work. > > >> > > >> Maybe we never assign to anyone who has never contributed anything of > > >> quality. And maybe we only assign once they have a draft PR that is > > >> looking good. > > >> > > >> Assigning issues is a relatively recent phenomenon in airflow. For > > most of > > >> the history people just did stuff without assigment -- afaik. So it's > > not > > >> necessary for working on something. > > >> > > >> > > >> > > >> > > >> > > >> On Thu, Feb 19, 2026 at 10:32 AM Jarek Potiuk <[email protected]> > wrote: > > >> > > >>>> 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, > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
