When I merge a PR, I take responsibility for the code long after the review ends. I took on a large open-source project before I started my career, while I was still learning the basics. I used to walk contributors through everything from Rust syntax to ways of solving problems in Rust. I wanted them to get as much as possible out of contributing. I still love open source. I’m not giving it up, and I want to welcome contributions that solve real problems in ways that fit the project. Some PRs, though, arrive without explaining why the change is needed or how anyone plans to use it. On a project as complex as SWC, even excellent AI tools can easily produce changes with bugs. Many PRs arrive without enough verification, so reviewing them takes a substantial amount of my time. Once merged, they also become my responsibility to maintain. That’s why I want to understand the problem behind a contribution: what happened, where the existing functionality falls short, and how you plan to use the proposed change. You don’t need to prove that a large service depends on it. A concrete problem you’ve experienced yourself is enough to start the conversation. That context helps me judge whether the change belongs in the project, whether the approach makes sense, and how we can solve the problem together.