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
