I am 0.5 on this. Whilst I agree that we need to do something to limit the number of spam PRs created by untrusted parties. blanket limit of say 5 on all contributors without write access is too restrictive. If you take me, for example, during very active periods I can have 15-20 open PRs. A policy like this would force me to close existing PRs that are currently in review if I want to open a new PR for an urgent fix. I feel that a blanket cap create needless friction for active contributors without write access, thereby discouraging them from contributing.
I think we could create a category of ‘trusted’ contributors (which may also include committers and collaborators) that are not subject to this cap. Thanks, Sameer. On Tue, 14 Jul 2026 at 17:11, Shivam Rastogi <[email protected]> wrote: > +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] > > > > >
