I believe this is a problem every open-source project faces. When describing someone's contribution to an open-source project, it's often not just about the number of pull requests merged. For example, it includes reviewing pull requests, providing detailed descriptions of issues when submitting Jira requests, and so on.
>From a certain perspective, Calcite is a very suitable project for vibe coding, which is inseparable from everyone's consistent contributions. Perhaps, in the future, we should pay more attention to the communication between contributors during pull request reviews (often with obvious AI involvement), whether they review other people's pull requests and offer reasonable suggestions, etc. Best wishes, Cancai Alessandro Solimando <[email protected]> 于2026年6月20日周六 01:35写道： > Hi, > that's a very tricky question nowadays. > > On top of the number of contributions, one important signal is how much > guidance is needed from when the PR is open to when it gets merged. > > If one person opens and merges a lot of PR but they need a lot of guidance, > and things don't improve (much) over time, I don't trust them > making the right choices tomorrow without guidance, be it for their own > code or for merging other people's PRs. > > How contributors review other people's code could possibly be used as a > proxy for their "judgment", but AI tools can do review too, so they need to > be meaningful. > > I have been thinking about this a lot lately, for OSS but also for my day > job, so I am particularly eager to hear your thoughts on this. > > Best regards, > Alessandro > > On Fri, 19 Jun 2026 at 02:03, jensen <[email protected]> wrote: > > > I fully understand Mihai’s concern. With AI today, it is very easy to fix > > bugs and add features, but people can do so without really understanding > > Calcite. Because of this, the number of PRs is no longer a reliable > signal > > of how familiar a contributor is with the project. > > > > > > AI can now assist with writing code, reviewing code, and even proposing > > design solutions. As a result, it is very difficult to determine from a > > single contribution whether someone used AI or whether they truly > > understand Calcite. > > > > > > However, over multiple contributions, we can still form a rough judgment. > > By looking at a combination of signals such as the number of PRs, review > > activity, and overall community engagement, we can gradually build > > confidence. In the end, it still comes down to trust from the community. > > > > > > > > Best regards, > > > > Zhen > > > > ---- Replied Message ---- > > | From | Mihai Budiu<[email protected]> | > > | Date | 06/19/2026 00:57 | > > | To | dev<[email protected]> | > > | Cc | | > > | Subject | promoting committers | > > Hello all, > > > > Today we invite a developer to become a committer after they make several > > useful non-trivial contributions to the project. But these days, using > > agents, the barrier of entry for contributing to a project has been > lowered > > substantially, and one can write useful code without a real understanding > > of the structure of a project. This is not a Calcite issue, I expect all > > open-source projects have to grapple with this. Does our committer > > selection process need adjustment? If so, how? > > > > Mihai > > >
