+1 on the cap. Not sure if we have any statistics which would help us determine the cap number. Going by my feeling, I would say 10, but having some aggregated statistics on how many open PRs contributors and first-time contributors had in the past could help us determine that.
> 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. Hi Sameer, Looking at the GitHub post, you can move an open PR to draft, and it won't be counted towards the limit. I also think that this side effect is a goal of the cap. When you have a limit for open PRs, you need to decide which one, from your perspective, is the most valuable for the project (or for you personally) and leave less valuable ones as drafts. It is also part of getting maintainers' time back. > 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. Hi Jarek, The idea sounds interesting to me. Probably most of the checks and evaluations could be deterministic at the end. But I'm not sure how well it would work. We have a couple of discussions open in some areas, from ownership (Code Owners discussion) to PR descriptions, which I think will affect the results of testing this idea. I think that we should go level by level, from the bottom, to raise the quality bar higher for open PRs with CI checks (not AI, just simple deterministic checks at the beginning) and bots which would do some actions based on the checks (the simplest one - put a comment on what should be fixed, potentially how, and move the PR to draft - I don't think we need human overview on simple comments following my way of thinking: "We as a maintainers expect you as a contributor to prepare the PR the best as you can. The same, you can expect as a contributor from maintainers that we will provide review as best as we can."). I would see AI review time evaluation as one of the last quality checks, as running this (AI) compute on something which not meet the quality baseline, IMHO, would be a waste of resources. Best, Przemek On 2026/07/14 16:28:14 Sameer Mesiah wrote: > 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] > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
