You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Jarek Potiuk <ja...@potiuk.com> on 2026/06/10 16:17:22 UTC
[DISCUSS] What do we do with unreviewed PRs - data based discussion
Hi everyone,
Building on Ash's recent discussion, I’d love to start a conversation about
how we handle our open PRs. While we explore PR templates and instructions,
I believe looking at our current data can help us find the best path
forward together.
I’ve been looking into the statistics from our last four weeks of triage
(you can see the details here:
https://gistpreview.github.io/?ff06225744d9386195510453190e354a), and I
wanted to share some encouraging insights:
- Out of 373 open PRs from non-maintainers, we’ve successfully identified
95 as Drafts. Most of these (70%) were moved to draft status during triage
to help authors focus on fixes, which keeps our main queue much leaner.
- We have 211 PRs "ready for maintainer review," meaning they pass all
our CI and testing criteria.
- Interestingly, about 108 of these are fully ready but haven't received
a comment yet, and 23 are approved and just waiting for a final merge.
The great news is that about 80% of our current triage actions are
deterministic! We could potentially automate these into CI scripts, which
would naturally clear about 100 items from our review queue. I’m more than
happy to help set this up if you think it’s a good next step.
I really value the human element in our community and want to make sure our
contributors feel heard.
Since many follow our criteria perfectly but still wait weeks for a
response, I’d love to hear your creative ideas on how we can better support
them and stay on top of these high-quality PRs.
What do you all think?
Best regards,
Jarek
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by Przemysław Mirowski <mi...@apache.org>.
> maybe it's a good idea to aim to work out an
> approach for handling incoming PRs for a cleaner start to 3.4?
+1
> There were a few ideas here and in other places. I am happy to review them
> and create a shared doc where we can discuss them in the meantime. Perhaps
> together we can - together - come up with some consensus on how to
> progress.
I think it is a good idea. Personally, I'm a bit lost where some threads are and having one place for the whole idea/discussion would be good. Also, we would see this more holistically, which should also make the process easier
And I'm pretty much agreeing with the rest.
On 2026/06/30 19:55:37 Jarek Potiuk wrote:
> Just a comment: while many of us are busy with Airflow 3 - so we should not
> distract those who are—maybe it's a good idea to aim to work out an
> approach for handling incoming PRs for a cleaner start to 3.4?
>
> There were a few ideas here and in other places. I am happy to review them
> and create a shared doc where we can discuss them in the meantime. Perhaps
> together we can - together - come up with some consensus on how to
> progress. I think the tension around releasing Airflow hinders discussions
> and reaching consensus, but possibly we could still get there.
>
> Broadly speaking I think the following approach is the next step:
>
> * Make a distinction between areas of contribution, regarding our
> "expectations". For example rules for the scheduler might differ from those
> for most providers, but the "standard" or "common" set of providers will
> follow yet another set of rules.
> * Limit the number of PRs a non-collaborator can have open; there is a
> feature released in GitHub last week we can use for it.
> * Limit the **SIZE** of a PR a non-collaborator can open - for example, <10
> lines (excluding tests) of "core" contributions will be okay; anything
> bigger will be rejected by CI
> * Limit the overall number of collaborator PRs that can be opened "per
> area" - this could be rejected by CI
> * For all defined areas, we **must** have maintainers who commit to
> reviewing those area PRs relatively quickly - this is very important
> * Write it down as a "Social Contract" we will follow - very important as
> well
>
> I think this approach has a number of benefits:
>
> * not closing for external contributions
> * but limiting them so that maintainers can find time for them
> * Teaching new contributors that small PRs are way better than bigger
>
> If this direction seems good, I'd be happy to run simulations on the
> currently "Ready for maintainer review" PRs to see the effect on our
> "incoming PRs" state. The outcome will naturally be different - the fact
> that we will start measuring it, will change the output - but I think it
> might be a good indication of the volume - per area - that will need a
> maintainer taking a look.
>
> We have all tooling in place to first experiment with it (Magpie) and then
> turn it into CI (Magpie rules -> Deterministic CI) is going to be a
> first-class citizen in Magpie.
>
> J.
>
>
>
>
>
> On Wed, Jun 24, 2026 at 5:26 PM Sameer Mesiah <sm...@gmail.com> wrote:
>
> > That is actually a fairly good heuristic. To expand on that idea, I think
> > we should exclude PRs that have been explicitly labelled as AI spam. I have
> > done a few reviews where I have written dozens of comments only to realize
> > that the author is just using an Agent to spam commits. And then the PR
> > gets closed without any of the comments being incorporated. We can also
> > account for what I call 'non-blocking' suggestions i.e. it's the author's
> > choice to implement. Does anybody else here have any ideas on how we
> > further build on this idea? Slop reviews are certainly a problem (though
> > not as endemic as Slop PRs). In some ways, they are worse, because you feel
> > gaslit but at the same time, you want feedback because you might be unsure
> > of something.
> >
> > On Tue, 23 Jun 2026 at 02:30, Ghaeli, Sean <gh...@amazon.com> wrote:
> >
> > > A way to prevent slop reviews is to weight an author's review score by
> > the
> > > extent to which it became incorporated in the implementation. A review
> > that
> > > results in no changes is given no weight.
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by Jarek Potiuk <ja...@potiuk.com>.
Just a comment: while many of us are busy with Airflow 3 - so we should not
distract those who are—maybe it's a good idea to aim to work out an
approach for handling incoming PRs for a cleaner start to 3.4?
There were a few ideas here and in other places. I am happy to review them
and create a shared doc where we can discuss them in the meantime. Perhaps
together we can - together - come up with some consensus on how to
progress. I think the tension around releasing Airflow hinders discussions
and reaching consensus, but possibly we could still get there.
Broadly speaking I think the following approach is the next step:
* Make a distinction between areas of contribution, regarding our
"expectations". For example rules for the scheduler might differ from those
for most providers, but the "standard" or "common" set of providers will
follow yet another set of rules.
* Limit the number of PRs a non-collaborator can have open; there is a
feature released in GitHub last week we can use for it.
* Limit the **SIZE** of a PR a non-collaborator can open - for example, <10
lines (excluding tests) of "core" contributions will be okay; anything
bigger will be rejected by CI
* Limit the overall number of collaborator PRs that can be opened "per
area" - this could be rejected by CI
* For all defined areas, we **must** have maintainers who commit to
reviewing those area PRs relatively quickly - this is very important
* Write it down as a "Social Contract" we will follow - very important as
well
I think this approach has a number of benefits:
* not closing for external contributions
* but limiting them so that maintainers can find time for them
* Teaching new contributors that small PRs are way better than bigger
If this direction seems good, I'd be happy to run simulations on the
currently "Ready for maintainer review" PRs to see the effect on our
"incoming PRs" state. The outcome will naturally be different - the fact
that we will start measuring it, will change the output - but I think it
might be a good indication of the volume - per area - that will need a
maintainer taking a look.
We have all tooling in place to first experiment with it (Magpie) and then
turn it into CI (Magpie rules -> Deterministic CI) is going to be a
first-class citizen in Magpie.
J.
On Wed, Jun 24, 2026 at 5:26 PM Sameer Mesiah <sm...@gmail.com> wrote:
> That is actually a fairly good heuristic. To expand on that idea, I think
> we should exclude PRs that have been explicitly labelled as AI spam. I have
> done a few reviews where I have written dozens of comments only to realize
> that the author is just using an Agent to spam commits. And then the PR
> gets closed without any of the comments being incorporated. We can also
> account for what I call 'non-blocking' suggestions i.e. it's the author's
> choice to implement. Does anybody else here have any ideas on how we
> further build on this idea? Slop reviews are certainly a problem (though
> not as endemic as Slop PRs). In some ways, they are worse, because you feel
> gaslit but at the same time, you want feedback because you might be unsure
> of something.
>
> On Tue, 23 Jun 2026 at 02:30, Ghaeli, Sean <gh...@amazon.com> wrote:
>
> > A way to prevent slop reviews is to weight an author's review score by
> the
> > extent to which it became incorporated in the implementation. A review
> that
> > results in no changes is given no weight.
> >
> >
>
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by Sameer Mesiah <sm...@gmail.com>.
That is actually a fairly good heuristic. To expand on that idea, I think
we should exclude PRs that have been explicitly labelled as AI spam. I have
done a few reviews where I have written dozens of comments only to realize
that the author is just using an Agent to spam commits. And then the PR
gets closed without any of the comments being incorporated. We can also
account for what I call 'non-blocking' suggestions i.e. it's the author's
choice to implement. Does anybody else here have any ideas on how we
further build on this idea? Slop reviews are certainly a problem (though
not as endemic as Slop PRs). In some ways, they are worse, because you feel
gaslit but at the same time, you want feedback because you might be unsure
of something.
On Tue, 23 Jun 2026 at 02:30, Ghaeli, Sean <gh...@amazon.com> wrote:
> A way to prevent slop reviews is to weight an author's review score by the
> extent to which it became incorporated in the implementation. A review that
> results in no changes is given no weight.
>
>
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by "Ghaeli, Sean" <gh...@amazon.com>.
A way to prevent slop reviews is to weight an author's review score by the extent to which it became incorporated in the implementation. A review that results in no changes is given no weight.
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by Sameer Mesiah <sm...@gmail.com>.
Hi Sean,
I was actually thinking of the exact same idea you just suggested i.e.
reward high volume reviewers with priority reviews on their PRs. This is a
great idea for reducing the 'drive-by' contributor where they just submit
PRs without investing in whittling down the review queue. It would also
encourage already active contributors to review more frequently. There is
of course a risk that this may be 'gamed' as well via agents or other means
so in addition to AI slop PRs, we may end up getting AI slop reviews. But
the biggest benefit would be incentivizing trusted contributors who care
about their reputation to spend more energy in reviews vs working on their
own PRs. This benefit cannot be understated as the biggest constraint is
review capacity not code generation.
Overall, strongly +1 in favour of this particular measure you proposed.
Thanks,
Sameer Mesiah.
On Sat, 20 Jun 2026 at 01:15, Ghaeli, Sean <gh...@amazon.com> wrote:
> Some stats I'm seeing plotted out:
>
> https://gist.github.com/seanghaeli/8fb41609f15c2ab403949cefbe43ff40
>
> Looking at the current queue of open PRs, there's a long-tailed
> distribution for PR age (first plot). I expected a strong correlation
> between PR age and its size (second plot), but the connection is quite weak
> (except for very large PRs spanning 1k+ lines). I'm interpreting PR size as
> a proxy for PR complexity.
>
> Seeing this, I think that there's room for a stronger forcing function to
> our review process to make that PR age distribution much steeper without
> diluting review quality. This goes back to my suggestion of explicitly
> weighting PR authors' level of contribution to other PR reviews, which
> would act as a natural forcing function.
>
> I'm not sure how to quantify it, but I suspect contributor retention would
> improve with quicker feedback loops on their work.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> For additional commands, e-mail: dev-help@airflow.apache.org
>
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by "Ghaeli, Sean" <gh...@amazon.com>.
Some stats I'm seeing plotted out:
https://gist.github.com/seanghaeli/8fb41609f15c2ab403949cefbe43ff40
Looking at the current queue of open PRs, there's a long-tailed distribution for PR age (first plot). I expected a strong correlation between PR age and its size (second plot), but the connection is quite weak (except for very large PRs spanning 1k+ lines). I'm interpreting PR size as a proxy for PR complexity.
Seeing this, I think that there's room for a stronger forcing function to our review process to make that PR age distribution much steeper without diluting review quality. This goes back to my suggestion of explicitly weighting PR authors' level of contribution to other PR reviews, which would act as a natural forcing function.
I'm not sure how to quantify it, but I suspect contributor retention would improve with quicker feedback loops on their work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by "Ghaeli, Sean" <gh...@amazon.com>.
One signal we can consider is whether a PR's author has been reviewing other people's PRs (perhaps with a recency filter as well). It's easy to compute and it rewards the behavior that shrinks the queue.
On 2026-06-10, 9:18 AM, "Jarek Potiuk" <jarek@potiuk.com <ma...@potiuk.com>> wrote:
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 everyone,
Building on Ash's recent discussion, I’d love to start a conversation about
how we handle our open PRs. While we explore PR templates and instructions,
I believe looking at our current data can help us find the best path
forward together.
I’ve been looking into the statistics from our last four weeks of triage
(you can see the details here:
https://gistpreview.github.io/?ff06225744d9386195510453190e354a <https://gistpreview.github.io/?ff06225744d9386195510453190e354a>), and I
wanted to share some encouraging insights:
- Out of 373 open PRs from non-maintainers, we’ve successfully identified
95 as Drafts. Most of these (70%) were moved to draft status during triage
to help authors focus on fixes, which keeps our main queue much leaner.
- We have 211 PRs "ready for maintainer review," meaning they pass all
our CI and testing criteria.
- Interestingly, about 108 of these are fully ready but haven't received
a comment yet, and 23 are approved and just waiting for a final merge.
The great news is that about 80% of our current triage actions are
deterministic! We could potentially automate these into CI scripts, which
would naturally clear about 100 items from our review queue. I’m more than
happy to help set this up if you think it’s a good next step.
I really value the human element in our community and want to make sure our
contributors feel heard.
Since many follow our criteria perfectly but still wait weeks for a
response, I’d love to hear your creative ideas on how we can better support
them and stay on top of these high-quality PRs.
What do you all think?
Best regards,
Jarek
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by Jarek Potiuk <ja...@potiuk.com>.
Hi everyone,
I agree with Amogh’s perspective; we have plenty of data to help us focus
on our process. To help with the noise, I’ve already implemented
"de-noising" for drafted PRs and am finishing up some helpful hooks in
Magpie to catch basic rule violations early on. Not planning anything else
until we agree on the next steps to handle the rising wave of "ready to
review" PRs, based on the trend from past months:
* April 3: 127
* May 19: 154
* June 10: 211
It feels like a good time to establish a shared community commitment
regarding how we prioritize and review PRs. While 211 PRs "ready for
review" sounds like a lot, I’m confident that by working together, we can
reverse the trend!
Here are a few examples of things we can do collaboratively:
- Create "fast close" guidelines in our PR criteria so maintainers feel
supported in quickly closing low-quality PRs (and commit to such quick
actions rather than leaving PRs unattended)
- Team up as stream reviewers and formalise this slightly, so we can
track it and possibly have stream owners raise their hand when they need
help if there are too many items for them to handle
- Prioritise some of those reviews and have clear criteria for which PRs
are going to be prioritised - so that we can communicate those
- Others ?
I personally think "ready for maintainer review" is a good starting point
to focus on having real conversations with humans. While doing this, we
might find other ways to further narrow that focus and add more criteria to
make those conversations with "real" humans.
What we really need now is for us (maintainers) to engage with those PRs
and establish a collective learning feedback loop. If we see cases that
seem like they should become "good PR" criteria, we should discuss them
here and propose those criteria based on the examples we see (and turn them
eventually into more automation). I think this is the only way we can turn
the trend downwards. It requires a bit of (pro)activity from us all.
No single person or automated tool can achieve this without others
contributing their time - for everyone's benefit.
I’m looking forward to sharing more stats at our dev calls, and I think it
would be great if we get some real proposals coming from this discussion
here and some lightweight social agreement on what we are going to do.
Best,
Jarek
On Thu, Jun 11, 2026 at 8:07 AM Amogh Desai <am...@apache.org> wrote:
> Airflow has reached a scale where contributor inflow is much higher
> compared to maintainer
> review capacity. Since the challenge now seems to be reviewer bandwidth and
> attention, especially
> during release periods when maintainers are naturally focused on
> release-critical work.
>
> The numbers Jarek shared are actually encouraging in one sense: many
> contributors are successfully
> getting their PRs into a reviewable state. That suggests the triage process
> is doing its job. The remaining
> bottleneck appears to be getting human eyes on those PRs.
>
> As a first step, perhaps we don’t need more tooling yet. It might be useful
> to regularly discuss these statistics during
> dev calls so we build shared visibility into the state of the reviewable
> PRs. We can also nudge swim lane owners which
> could help us identify where attention is needed.
>
> Once we have that visibility and agreement that review throughput is
> something we want to improve, we can explore
> whether ownership, prioritization, or automation can help.
>
> Thanks & Regards,
> Amogh Desai
>
>
> On Thu, Jun 11, 2026 at 4:45 AM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > Hi everyone,
> >
> > Thank you, Sameer, for those suggestions. Incorporating urgency,
> > contributor history, and PR quality are good ideas for improving our
> > workflow.
> >
> > The key is defining these standards together. We can easily codify these
> > priorities in our Pull Request Quality Criteria (
> >
> >
> https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#id2
> > ).
> > Once we agree on these benchmarks, the triage process can naturally use
> > them (it's currently using those).
> >
> > I’d love to see a few of us team up to draft these descriptions. If we
> > reach a consensus on what a "high-priority" PR looks like, we could even
> > use LLMs to help with the classification.
> > I believe that with our collective willpower, we can better support the
> > humans waiting for our feedback there. But we need - I think a
> > collective agreement on acknowledging this is a problem and some kind of
> > social contract between us here that we would like to solve it.
> >
> > What does everyone think?
> >
> > Best regards,
> > Jarek
> >
> >
> > On Wed, Jun 10, 2026 at 10:18 PM Sameer Mesiah <sm...@gmail.com>
> > wrote:
> >
> > > Hi Jarek,
> > >
> > > I think the issue might be that the 'ready for maintainer review'
> > > label might be too broad. Perhaps, your auto-triage tool could
> > incorporate
> > > an automated ranking system that categorizes each by PR using criteria
> > such
> > > as:
> > >
> > > 1) Urgency (PRs that need to be merged for the upcoming releases should
> > be
> > > reviewed first)
> > > 2) Contributor History (perhaps contributors above a certain threshold
> of
> > > merges could be prioritized)
> > > 3) PR quality (this may include a multitude of criteria including
> testing
> > > and documentation)
> > >
> > > Note that the above is not an exhaustive list. The basic idea is
> creating
> > > multiple categories from 'most reviewable' to 'least reviewable' (which
> > is
> > > currently collapsed under the 'ready for maintainer review' label).
> This
> > > will save time that is currently spent by maintainers pointing out
> basic
> > > issues in lower quality PRs. Granted, there is a possibility for false
> > > categorizations here. Therefore, a manual override might be needed if a
> > > high quality PR has been miscategorized as low quality.
> > >
> > > Thanks,
> > > Sameer.
> > >
> > > On Wed, 10 Jun 2026 at 18:29, Jarek Potiuk <ja...@potiuk.com> wrote:
> > >
> > > > > I think the process of getting many PRs into green in terms of CI
> > pass
> > > > while no meaningful review done is causing a lot of noise.
> > > >
> > > > That's an interesting comment; I'm glad you raised it. There is an
> easy
> > > way
> > > > to avoid it - instead of not commenting on them at all, not drafting
> > > them,
> > > > and not sending comments. I can easily see how we could avoid the
> > message
> > > > noise—for example we could just turn the PR into a draft and "fold"
> the
> > > > instructions into the PR itself. This technique works well for
> Security
> > > > issues, and we could employ it instead. It won't generate additional
> > > noise
> > > > - and should have the same effect (It can still be done
> > > deterministically).
> > > >
> > > > This way we could keep the same process, and draft PRs that need
> > fixing.
> > > >
> > > > Would that also solve your problem? And yes I see that as a problem
> for
> > > > people who are using "emails" or notifications as a signal, so
> that's a
> > > > very fair statement.
> > > >
> > > > Just to clarify: Actually turning the PRs to "ready for maintainer
> > > review"
> > > > does not send any message in the PR thread so we do not need to do
> much
> > > > about it.
> > > >
> > > > > My recommendation would be to tune down running the tools. Maybe
> > focus
> > > on
> > > > > 20 PRs to the finish line and only then move to the next batch.
> > > > > Getting 200 PRs into "ready" is proven not useful I think.
> > > > If you look at the stats - this already happens - most of the PRs
> that
> > > get
> > > > "ready" are not those we drafted. We only turn PRs into "ready for
> > > > maintainers" when they are genuinely ready - so all tests passing,
> and
> > > > other "basic" criteria are met. Also note that we have not turned
> those
> > > 200
> > > > PRs into "ready" overnight. If you look at previous reports they are
> > > slowly
> > > > accumulating - and the "20 at a time" volume is far more than what we
> > > > handle on a daily basis
> > > >
> > > > I do not think we have a problem with "marking PRs ready," but with
> > > > handling those that are ready.
> > > >
> > > > J,
> > > >
> > > >
> > > > On Wed, Jun 10, 2026 at 6:51 PM Elad Kalif <el...@apache.org>
> wrote:
> > > >
> > > > > I think the process of getting many PRs into green in terms of CI
> > pass
> > > > > while no meaningful review done is causing a lot of noise.
> > > > > My mailbox is swamped and this actually causes me to miss human
> > > comments
> > > > > across PRs that I track.
> > > > > At least for me, it takes longer to track the PRs that I can help
> > > review
> > > > > and merge due to that noise. The "ready for maintainer review" is
> not
> > > > > useful for me.
> > > > >
> > > > > My recommendation would be to tune down running the tools. Maybe
> > focus
> > > on
> > > > > 20 PRs to the finish line and only then move to the next batch.
> > > > > Getting 200 PRs into "ready" is proven not useful I think.
> > > > >
> > > > >
> > > > > On Wed, Jun 10, 2026 at 7:17 PM Jarek Potiuk <ja...@potiuk.com>
> > wrote:
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > Building on Ash's recent discussion, I’d love to start a
> > conversation
> > > > > about
> > > > > > how we handle our open PRs. While we explore PR templates and
> > > > > instructions,
> > > > > > I believe looking at our current data can help us find the best
> > path
> > > > > > forward together.
> > > > > >
> > > > > > I’ve been looking into the statistics from our last four weeks of
> > > > triage
> > > > > > (you can see the details here:
> > > > > > https://gistpreview.github.io/?ff06225744d9386195510453190e354a
> ),
> > > and
> > > > I
> > > > > > wanted to share some encouraging insights:
> > > > > >
> > > > > > - Out of 373 open PRs from non-maintainers, we’ve successfully
> > > > > identified
> > > > > > 95 as Drafts. Most of these (70%) were moved to draft status
> during
> > > > > triage
> > > > > > to help authors focus on fixes, which keeps our main queue much
> > > leaner.
> > > > > > - We have 211 PRs "ready for maintainer review," meaning they
> > pass
> > > > all
> > > > > > our CI and testing criteria.
> > > > > > - Interestingly, about 108 of these are fully ready but haven't
> > > > > received
> > > > > > a comment yet, and 23 are approved and just waiting for a final
> > > merge.
> > > > > >
> > > > > > The great news is that about 80% of our current triage actions
> are
> > > > > > deterministic! We could potentially automate these into CI
> scripts,
> > > > which
> > > > > > would naturally clear about 100 items from our review queue. I’m
> > more
> > > > > than
> > > > > > happy to help set this up if you think it’s a good next step.
> > > > > >
> > > > > > I really value the human element in our community and want to
> make
> > > sure
> > > > > our
> > > > > > contributors feel heard.
> > > > > >
> > > > > > Since many follow our criteria perfectly but still wait weeks
> for a
> > > > > > response, I’d love to hear your creative ideas on how we can
> better
> > > > > support
> > > > > > them and stay on top of these high-quality PRs.
> > > > > >
> > > > > > What do you all think?
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Jarek
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by Amogh Desai <am...@apache.org>.
Airflow has reached a scale where contributor inflow is much higher
compared to maintainer
review capacity. Since the challenge now seems to be reviewer bandwidth and
attention, especially
during release periods when maintainers are naturally focused on
release-critical work.
The numbers Jarek shared are actually encouraging in one sense: many
contributors are successfully
getting their PRs into a reviewable state. That suggests the triage process
is doing its job. The remaining
bottleneck appears to be getting human eyes on those PRs.
As a first step, perhaps we don’t need more tooling yet. It might be useful
to regularly discuss these statistics during
dev calls so we build shared visibility into the state of the reviewable
PRs. We can also nudge swim lane owners which
could help us identify where attention is needed.
Once we have that visibility and agreement that review throughput is
something we want to improve, we can explore
whether ownership, prioritization, or automation can help.
Thanks & Regards,
Amogh Desai
On Thu, Jun 11, 2026 at 4:45 AM Jarek Potiuk <ja...@potiuk.com> wrote:
> Hi everyone,
>
> Thank you, Sameer, for those suggestions. Incorporating urgency,
> contributor history, and PR quality are good ideas for improving our
> workflow.
>
> The key is defining these standards together. We can easily codify these
> priorities in our Pull Request Quality Criteria (
>
> https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#id2
> ).
> Once we agree on these benchmarks, the triage process can naturally use
> them (it's currently using those).
>
> I’d love to see a few of us team up to draft these descriptions. If we
> reach a consensus on what a "high-priority" PR looks like, we could even
> use LLMs to help with the classification.
> I believe that with our collective willpower, we can better support the
> humans waiting for our feedback there. But we need - I think a
> collective agreement on acknowledging this is a problem and some kind of
> social contract between us here that we would like to solve it.
>
> What does everyone think?
>
> Best regards,
> Jarek
>
>
> On Wed, Jun 10, 2026 at 10:18 PM Sameer Mesiah <sm...@gmail.com>
> wrote:
>
> > Hi Jarek,
> >
> > I think the issue might be that the 'ready for maintainer review'
> > label might be too broad. Perhaps, your auto-triage tool could
> incorporate
> > an automated ranking system that categorizes each by PR using criteria
> such
> > as:
> >
> > 1) Urgency (PRs that need to be merged for the upcoming releases should
> be
> > reviewed first)
> > 2) Contributor History (perhaps contributors above a certain threshold of
> > merges could be prioritized)
> > 3) PR quality (this may include a multitude of criteria including testing
> > and documentation)
> >
> > Note that the above is not an exhaustive list. The basic idea is creating
> > multiple categories from 'most reviewable' to 'least reviewable' (which
> is
> > currently collapsed under the 'ready for maintainer review' label). This
> > will save time that is currently spent by maintainers pointing out basic
> > issues in lower quality PRs. Granted, there is a possibility for false
> > categorizations here. Therefore, a manual override might be needed if a
> > high quality PR has been miscategorized as low quality.
> >
> > Thanks,
> > Sameer.
> >
> > On Wed, 10 Jun 2026 at 18:29, Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > > > I think the process of getting many PRs into green in terms of CI
> pass
> > > while no meaningful review done is causing a lot of noise.
> > >
> > > That's an interesting comment; I'm glad you raised it. There is an easy
> > way
> > > to avoid it - instead of not commenting on them at all, not drafting
> > them,
> > > and not sending comments. I can easily see how we could avoid the
> message
> > > noise—for example we could just turn the PR into a draft and "fold" the
> > > instructions into the PR itself. This technique works well for Security
> > > issues, and we could employ it instead. It won't generate additional
> > noise
> > > - and should have the same effect (It can still be done
> > deterministically).
> > >
> > > This way we could keep the same process, and draft PRs that need
> fixing.
> > >
> > > Would that also solve your problem? And yes I see that as a problem for
> > > people who are using "emails" or notifications as a signal, so that's a
> > > very fair statement.
> > >
> > > Just to clarify: Actually turning the PRs to "ready for maintainer
> > review"
> > > does not send any message in the PR thread so we do not need to do much
> > > about it.
> > >
> > > > My recommendation would be to tune down running the tools. Maybe
> focus
> > on
> > > > 20 PRs to the finish line and only then move to the next batch.
> > > > Getting 200 PRs into "ready" is proven not useful I think.
> > > If you look at the stats - this already happens - most of the PRs that
> > get
> > > "ready" are not those we drafted. We only turn PRs into "ready for
> > > maintainers" when they are genuinely ready - so all tests passing, and
> > > other "basic" criteria are met. Also note that we have not turned those
> > 200
> > > PRs into "ready" overnight. If you look at previous reports they are
> > slowly
> > > accumulating - and the "20 at a time" volume is far more than what we
> > > handle on a daily basis
> > >
> > > I do not think we have a problem with "marking PRs ready," but with
> > > handling those that are ready.
> > >
> > > J,
> > >
> > >
> > > On Wed, Jun 10, 2026 at 6:51 PM Elad Kalif <el...@apache.org> wrote:
> > >
> > > > I think the process of getting many PRs into green in terms of CI
> pass
> > > > while no meaningful review done is causing a lot of noise.
> > > > My mailbox is swamped and this actually causes me to miss human
> > comments
> > > > across PRs that I track.
> > > > At least for me, it takes longer to track the PRs that I can help
> > review
> > > > and merge due to that noise. The "ready for maintainer review" is not
> > > > useful for me.
> > > >
> > > > My recommendation would be to tune down running the tools. Maybe
> focus
> > on
> > > > 20 PRs to the finish line and only then move to the next batch.
> > > > Getting 200 PRs into "ready" is proven not useful I think.
> > > >
> > > >
> > > > On Wed, Jun 10, 2026 at 7:17 PM Jarek Potiuk <ja...@potiuk.com>
> wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > Building on Ash's recent discussion, I’d love to start a
> conversation
> > > > about
> > > > > how we handle our open PRs. While we explore PR templates and
> > > > instructions,
> > > > > I believe looking at our current data can help us find the best
> path
> > > > > forward together.
> > > > >
> > > > > I’ve been looking into the statistics from our last four weeks of
> > > triage
> > > > > (you can see the details here:
> > > > > https://gistpreview.github.io/?ff06225744d9386195510453190e354a),
> > and
> > > I
> > > > > wanted to share some encouraging insights:
> > > > >
> > > > > - Out of 373 open PRs from non-maintainers, we’ve successfully
> > > > identified
> > > > > 95 as Drafts. Most of these (70%) were moved to draft status during
> > > > triage
> > > > > to help authors focus on fixes, which keeps our main queue much
> > leaner.
> > > > > - We have 211 PRs "ready for maintainer review," meaning they
> pass
> > > all
> > > > > our CI and testing criteria.
> > > > > - Interestingly, about 108 of these are fully ready but haven't
> > > > received
> > > > > a comment yet, and 23 are approved and just waiting for a final
> > merge.
> > > > >
> > > > > The great news is that about 80% of our current triage actions are
> > > > > deterministic! We could potentially automate these into CI scripts,
> > > which
> > > > > would naturally clear about 100 items from our review queue. I’m
> more
> > > > than
> > > > > happy to help set this up if you think it’s a good next step.
> > > > >
> > > > > I really value the human element in our community and want to make
> > sure
> > > > our
> > > > > contributors feel heard.
> > > > >
> > > > > Since many follow our criteria perfectly but still wait weeks for a
> > > > > response, I’d love to hear your creative ideas on how we can better
> > > > support
> > > > > them and stay on top of these high-quality PRs.
> > > > >
> > > > > What do you all think?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Jarek
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by Jarek Potiuk <ja...@potiuk.com>.
Hi everyone,
Thank you, Sameer, for those suggestions. Incorporating urgency,
contributor history, and PR quality are good ideas for improving our
workflow.
The key is defining these standards together. We can easily codify these
priorities in our Pull Request Quality Criteria (
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#id2).
Once we agree on these benchmarks, the triage process can naturally use
them (it's currently using those).
I’d love to see a few of us team up to draft these descriptions. If we
reach a consensus on what a "high-priority" PR looks like, we could even
use LLMs to help with the classification.
I believe that with our collective willpower, we can better support the
humans waiting for our feedback there. But we need - I think a
collective agreement on acknowledging this is a problem and some kind of
social contract between us here that we would like to solve it.
What does everyone think?
Best regards,
Jarek
On Wed, Jun 10, 2026 at 10:18 PM Sameer Mesiah <sm...@gmail.com> wrote:
> Hi Jarek,
>
> I think the issue might be that the 'ready for maintainer review'
> label might be too broad. Perhaps, your auto-triage tool could incorporate
> an automated ranking system that categorizes each by PR using criteria such
> as:
>
> 1) Urgency (PRs that need to be merged for the upcoming releases should be
> reviewed first)
> 2) Contributor History (perhaps contributors above a certain threshold of
> merges could be prioritized)
> 3) PR quality (this may include a multitude of criteria including testing
> and documentation)
>
> Note that the above is not an exhaustive list. The basic idea is creating
> multiple categories from 'most reviewable' to 'least reviewable' (which is
> currently collapsed under the 'ready for maintainer review' label). This
> will save time that is currently spent by maintainers pointing out basic
> issues in lower quality PRs. Granted, there is a possibility for false
> categorizations here. Therefore, a manual override might be needed if a
> high quality PR has been miscategorized as low quality.
>
> Thanks,
> Sameer.
>
> On Wed, 10 Jun 2026 at 18:29, Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > > I think the process of getting many PRs into green in terms of CI pass
> > while no meaningful review done is causing a lot of noise.
> >
> > That's an interesting comment; I'm glad you raised it. There is an easy
> way
> > to avoid it - instead of not commenting on them at all, not drafting
> them,
> > and not sending comments. I can easily see how we could avoid the message
> > noise—for example we could just turn the PR into a draft and "fold" the
> > instructions into the PR itself. This technique works well for Security
> > issues, and we could employ it instead. It won't generate additional
> noise
> > - and should have the same effect (It can still be done
> deterministically).
> >
> > This way we could keep the same process, and draft PRs that need fixing.
> >
> > Would that also solve your problem? And yes I see that as a problem for
> > people who are using "emails" or notifications as a signal, so that's a
> > very fair statement.
> >
> > Just to clarify: Actually turning the PRs to "ready for maintainer
> review"
> > does not send any message in the PR thread so we do not need to do much
> > about it.
> >
> > > My recommendation would be to tune down running the tools. Maybe focus
> on
> > > 20 PRs to the finish line and only then move to the next batch.
> > > Getting 200 PRs into "ready" is proven not useful I think.
> > If you look at the stats - this already happens - most of the PRs that
> get
> > "ready" are not those we drafted. We only turn PRs into "ready for
> > maintainers" when they are genuinely ready - so all tests passing, and
> > other "basic" criteria are met. Also note that we have not turned those
> 200
> > PRs into "ready" overnight. If you look at previous reports they are
> slowly
> > accumulating - and the "20 at a time" volume is far more than what we
> > handle on a daily basis
> >
> > I do not think we have a problem with "marking PRs ready," but with
> > handling those that are ready.
> >
> > J,
> >
> >
> > On Wed, Jun 10, 2026 at 6:51 PM Elad Kalif <el...@apache.org> wrote:
> >
> > > I think the process of getting many PRs into green in terms of CI pass
> > > while no meaningful review done is causing a lot of noise.
> > > My mailbox is swamped and this actually causes me to miss human
> comments
> > > across PRs that I track.
> > > At least for me, it takes longer to track the PRs that I can help
> review
> > > and merge due to that noise. The "ready for maintainer review" is not
> > > useful for me.
> > >
> > > My recommendation would be to tune down running the tools. Maybe focus
> on
> > > 20 PRs to the finish line and only then move to the next batch.
> > > Getting 200 PRs into "ready" is proven not useful I think.
> > >
> > >
> > > On Wed, Jun 10, 2026 at 7:17 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > Building on Ash's recent discussion, I’d love to start a conversation
> > > about
> > > > how we handle our open PRs. While we explore PR templates and
> > > instructions,
> > > > I believe looking at our current data can help us find the best path
> > > > forward together.
> > > >
> > > > I’ve been looking into the statistics from our last four weeks of
> > triage
> > > > (you can see the details here:
> > > > https://gistpreview.github.io/?ff06225744d9386195510453190e354a),
> and
> > I
> > > > wanted to share some encouraging insights:
> > > >
> > > > - Out of 373 open PRs from non-maintainers, we’ve successfully
> > > identified
> > > > 95 as Drafts. Most of these (70%) were moved to draft status during
> > > triage
> > > > to help authors focus on fixes, which keeps our main queue much
> leaner.
> > > > - We have 211 PRs "ready for maintainer review," meaning they pass
> > all
> > > > our CI and testing criteria.
> > > > - Interestingly, about 108 of these are fully ready but haven't
> > > received
> > > > a comment yet, and 23 are approved and just waiting for a final
> merge.
> > > >
> > > > The great news is that about 80% of our current triage actions are
> > > > deterministic! We could potentially automate these into CI scripts,
> > which
> > > > would naturally clear about 100 items from our review queue. I’m more
> > > than
> > > > happy to help set this up if you think it’s a good next step.
> > > >
> > > > I really value the human element in our community and want to make
> sure
> > > our
> > > > contributors feel heard.
> > > >
> > > > Since many follow our criteria perfectly but still wait weeks for a
> > > > response, I’d love to hear your creative ideas on how we can better
> > > support
> > > > them and stay on top of these high-quality PRs.
> > > >
> > > > What do you all think?
> > > >
> > > > Best regards,
> > > >
> > > > Jarek
> > > >
> > >
> >
>
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by Sameer Mesiah <sm...@gmail.com>.
Hi Jarek,
I think the issue might be that the 'ready for maintainer review'
label might be too broad. Perhaps, your auto-triage tool could incorporate
an automated ranking system that categorizes each by PR using criteria such
as:
1) Urgency (PRs that need to be merged for the upcoming releases should be
reviewed first)
2) Contributor History (perhaps contributors above a certain threshold of
merges could be prioritized)
3) PR quality (this may include a multitude of criteria including testing
and documentation)
Note that the above is not an exhaustive list. The basic idea is creating
multiple categories from 'most reviewable' to 'least reviewable' (which is
currently collapsed under the 'ready for maintainer review' label). This
will save time that is currently spent by maintainers pointing out basic
issues in lower quality PRs. Granted, there is a possibility for false
categorizations here. Therefore, a manual override might be needed if a
high quality PR has been miscategorized as low quality.
Thanks,
Sameer.
On Wed, 10 Jun 2026 at 18:29, Jarek Potiuk <ja...@potiuk.com> wrote:
> > I think the process of getting many PRs into green in terms of CI pass
> while no meaningful review done is causing a lot of noise.
>
> That's an interesting comment; I'm glad you raised it. There is an easy way
> to avoid it - instead of not commenting on them at all, not drafting them,
> and not sending comments. I can easily see how we could avoid the message
> noise—for example we could just turn the PR into a draft and "fold" the
> instructions into the PR itself. This technique works well for Security
> issues, and we could employ it instead. It won't generate additional noise
> - and should have the same effect (It can still be done deterministically).
>
> This way we could keep the same process, and draft PRs that need fixing.
>
> Would that also solve your problem? And yes I see that as a problem for
> people who are using "emails" or notifications as a signal, so that's a
> very fair statement.
>
> Just to clarify: Actually turning the PRs to "ready for maintainer review"
> does not send any message in the PR thread so we do not need to do much
> about it.
>
> > My recommendation would be to tune down running the tools. Maybe focus on
> > 20 PRs to the finish line and only then move to the next batch.
> > Getting 200 PRs into "ready" is proven not useful I think.
> If you look at the stats - this already happens - most of the PRs that get
> "ready" are not those we drafted. We only turn PRs into "ready for
> maintainers" when they are genuinely ready - so all tests passing, and
> other "basic" criteria are met. Also note that we have not turned those 200
> PRs into "ready" overnight. If you look at previous reports they are slowly
> accumulating - and the "20 at a time" volume is far more than what we
> handle on a daily basis
>
> I do not think we have a problem with "marking PRs ready," but with
> handling those that are ready.
>
> J,
>
>
> On Wed, Jun 10, 2026 at 6:51 PM Elad Kalif <el...@apache.org> wrote:
>
> > I think the process of getting many PRs into green in terms of CI pass
> > while no meaningful review done is causing a lot of noise.
> > My mailbox is swamped and this actually causes me to miss human comments
> > across PRs that I track.
> > At least for me, it takes longer to track the PRs that I can help review
> > and merge due to that noise. The "ready for maintainer review" is not
> > useful for me.
> >
> > My recommendation would be to tune down running the tools. Maybe focus on
> > 20 PRs to the finish line and only then move to the next batch.
> > Getting 200 PRs into "ready" is proven not useful I think.
> >
> >
> > On Wed, Jun 10, 2026 at 7:17 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > > Hi everyone,
> > >
> > > Building on Ash's recent discussion, I’d love to start a conversation
> > about
> > > how we handle our open PRs. While we explore PR templates and
> > instructions,
> > > I believe looking at our current data can help us find the best path
> > > forward together.
> > >
> > > I’ve been looking into the statistics from our last four weeks of
> triage
> > > (you can see the details here:
> > > https://gistpreview.github.io/?ff06225744d9386195510453190e354a), and
> I
> > > wanted to share some encouraging insights:
> > >
> > > - Out of 373 open PRs from non-maintainers, we’ve successfully
> > identified
> > > 95 as Drafts. Most of these (70%) were moved to draft status during
> > triage
> > > to help authors focus on fixes, which keeps our main queue much leaner.
> > > - We have 211 PRs "ready for maintainer review," meaning they pass
> all
> > > our CI and testing criteria.
> > > - Interestingly, about 108 of these are fully ready but haven't
> > received
> > > a comment yet, and 23 are approved and just waiting for a final merge.
> > >
> > > The great news is that about 80% of our current triage actions are
> > > deterministic! We could potentially automate these into CI scripts,
> which
> > > would naturally clear about 100 items from our review queue. I’m more
> > than
> > > happy to help set this up if you think it’s a good next step.
> > >
> > > I really value the human element in our community and want to make sure
> > our
> > > contributors feel heard.
> > >
> > > Since many follow our criteria perfectly but still wait weeks for a
> > > response, I’d love to hear your creative ideas on how we can better
> > support
> > > them and stay on top of these high-quality PRs.
> > >
> > > What do you all think?
> > >
> > > Best regards,
> > >
> > > Jarek
> > >
> >
>
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by Jarek Potiuk <ja...@potiuk.com>.
> I think the process of getting many PRs into green in terms of CI pass
while no meaningful review done is causing a lot of noise.
That's an interesting comment; I'm glad you raised it. There is an easy way
to avoid it - instead of not commenting on them at all, not drafting them,
and not sending comments. I can easily see how we could avoid the message
noise—for example we could just turn the PR into a draft and "fold" the
instructions into the PR itself. This technique works well for Security
issues, and we could employ it instead. It won't generate additional noise
- and should have the same effect (It can still be done deterministically).
This way we could keep the same process, and draft PRs that need fixing.
Would that also solve your problem? And yes I see that as a problem for
people who are using "emails" or notifications as a signal, so that's a
very fair statement.
Just to clarify: Actually turning the PRs to "ready for maintainer review"
does not send any message in the PR thread so we do not need to do much
about it.
> My recommendation would be to tune down running the tools. Maybe focus on
> 20 PRs to the finish line and only then move to the next batch.
> Getting 200 PRs into "ready" is proven not useful I think.
If you look at the stats - this already happens - most of the PRs that get
"ready" are not those we drafted. We only turn PRs into "ready for
maintainers" when they are genuinely ready - so all tests passing, and
other "basic" criteria are met. Also note that we have not turned those 200
PRs into "ready" overnight. If you look at previous reports they are slowly
accumulating - and the "20 at a time" volume is far more than what we
handle on a daily basis
I do not think we have a problem with "marking PRs ready," but with
handling those that are ready.
J,
On Wed, Jun 10, 2026 at 6:51 PM Elad Kalif <el...@apache.org> wrote:
> I think the process of getting many PRs into green in terms of CI pass
> while no meaningful review done is causing a lot of noise.
> My mailbox is swamped and this actually causes me to miss human comments
> across PRs that I track.
> At least for me, it takes longer to track the PRs that I can help review
> and merge due to that noise. The "ready for maintainer review" is not
> useful for me.
>
> My recommendation would be to tune down running the tools. Maybe focus on
> 20 PRs to the finish line and only then move to the next batch.
> Getting 200 PRs into "ready" is proven not useful I think.
>
>
> On Wed, Jun 10, 2026 at 7:17 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > Hi everyone,
> >
> > Building on Ash's recent discussion, I’d love to start a conversation
> about
> > how we handle our open PRs. While we explore PR templates and
> instructions,
> > I believe looking at our current data can help us find the best path
> > forward together.
> >
> > I’ve been looking into the statistics from our last four weeks of triage
> > (you can see the details here:
> > https://gistpreview.github.io/?ff06225744d9386195510453190e354a), and I
> > wanted to share some encouraging insights:
> >
> > - Out of 373 open PRs from non-maintainers, we’ve successfully
> identified
> > 95 as Drafts. Most of these (70%) were moved to draft status during
> triage
> > to help authors focus on fixes, which keeps our main queue much leaner.
> > - We have 211 PRs "ready for maintainer review," meaning they pass all
> > our CI and testing criteria.
> > - Interestingly, about 108 of these are fully ready but haven't
> received
> > a comment yet, and 23 are approved and just waiting for a final merge.
> >
> > The great news is that about 80% of our current triage actions are
> > deterministic! We could potentially automate these into CI scripts, which
> > would naturally clear about 100 items from our review queue. I’m more
> than
> > happy to help set this up if you think it’s a good next step.
> >
> > I really value the human element in our community and want to make sure
> our
> > contributors feel heard.
> >
> > Since many follow our criteria perfectly but still wait weeks for a
> > response, I’d love to hear your creative ideas on how we can better
> support
> > them and stay on top of these high-quality PRs.
> >
> > What do you all think?
> >
> > Best regards,
> >
> > Jarek
> >
>
Re: [DISCUSS] What do we do with unreviewed PRs - data based discussion
Posted by Elad Kalif <el...@apache.org>.
I think the process of getting many PRs into green in terms of CI pass
while no meaningful review done is causing a lot of noise.
My mailbox is swamped and this actually causes me to miss human comments
across PRs that I track.
At least for me, it takes longer to track the PRs that I can help review
and merge due to that noise. The "ready for maintainer review" is not
useful for me.
My recommendation would be to tune down running the tools. Maybe focus on
20 PRs to the finish line and only then move to the next batch.
Getting 200 PRs into "ready" is proven not useful I think.
On Wed, Jun 10, 2026 at 7:17 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> Hi everyone,
>
> Building on Ash's recent discussion, I’d love to start a conversation about
> how we handle our open PRs. While we explore PR templates and instructions,
> I believe looking at our current data can help us find the best path
> forward together.
>
> I’ve been looking into the statistics from our last four weeks of triage
> (you can see the details here:
> https://gistpreview.github.io/?ff06225744d9386195510453190e354a), and I
> wanted to share some encouraging insights:
>
> - Out of 373 open PRs from non-maintainers, we’ve successfully identified
> 95 as Drafts. Most of these (70%) were moved to draft status during triage
> to help authors focus on fixes, which keeps our main queue much leaner.
> - We have 211 PRs "ready for maintainer review," meaning they pass all
> our CI and testing criteria.
> - Interestingly, about 108 of these are fully ready but haven't received
> a comment yet, and 23 are approved and just waiting for a final merge.
>
> The great news is that about 80% of our current triage actions are
> deterministic! We could potentially automate these into CI scripts, which
> would naturally clear about 100 items from our review queue. I’m more than
> happy to help set this up if you think it’s a good next step.
>
> I really value the human element in our community and want to make sure our
> contributors feel heard.
>
> Since many follow our criteria perfectly but still wait weeks for a
> response, I’d love to hear your creative ideas on how we can better support
> them and stay on top of these high-quality PRs.
>
> What do you all think?
>
> Best regards,
>
> Jarek
>