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