Lazy consensus started in https://lists.apache.org/thread/xo6rsg3csmdtqw9s74t6mzkzsddxdbcq
On Tue, Feb 24, 2026 at 3:40 PM Jarek Potiuk <[email protected]> wrote: > 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] >> > >> > >> >
