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] > >
