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]
