+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]
