+1 on adding a cap. As a contributor without write access, I’d like to offer one perspective for when we decide on the limit.
Reviews can take time, and some PRs depend on others, especially if you are working in a new area. I have occasionally had 8–10 legitimate PRs open at once. A limit in the 10–15 range might strike a good balance: preventing floods while leaving room for active contributors whose PRs are awaiting review or blocked on related work. Either way, I support the direction. Thanks for pushing this forward. Regards, Shivam On Mon, 13 Jul 2026 at 12:18, Henry Chen <[email protected]> wrote: > +1 on the cap, thanks for pushing this. > > Henry > > On 2026/07/09 18:37:41 Jarek Potiuk wrote: > > Hello everyone, > > > > I’ve been testing our triage process recently, quietly closing or > reviewing > > PRs based on our current criteria. It seems to be working smoothly—we’ve > > handled about 60 PRs over the last few weeks with minimal disruption! I’m > > excited to share that we are nearly ready to move most of these checks to > > an automated CI process - following Magpie's "Autonomous mode when we > prove > > it works with supervision". > > > > I’ve been thinking about how we can best "give back time to maintainers" > > and have a proposal for a more helpful, intuitive strategy. > > > > What if we use "maintainer time" as our main guide? Specifically, we > could > > use AI to help assess if a PR would take significantly more time to > review > > than it would take a maintainer to create it. This should allow us to > focus > > our energy where it matters most. > > > > We can customize this by area. For example, critical core components > > require high-scale testing, while provider updates might be simpler to > > verify regardless of size. By factoring in code complexity and > > area-specific needs, we can calibrate a "bar" that keeps our queue > > manageable and high-quality. > > > > We have over 230 open test cases in our repo that we can use for > > calibration. > > > > My goal is to provide clear, kind feedback to contributors when a PR is > > closed based on the assessment of its complexity and the resulting > > "maintainer time for review," suggesting they start with smaller fixes or > > different areas. This isn’t about being restrictive, but about ensuring > our > > community’s time is used effectively. > > > > I’m happy to draft these initial criteria and collaborate with area > > "stewards" to refine them. I’d love to hear your thoughts on making this > a > > shared "social contract" to keep our project healthy and sustainable. > > > > This would demand a level of proactiveness from us—for example it would > be > > up to the area "stewards" impacted to tighten the criteria they set and > > describe the area's complexity, which would raise the bar for > contributors. > > > > Best, > > Jarek > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
