If you want to be a Calcite committer, find a way to communicate concisely.
The scarce resource today is not code but people’s attention. Therefore we would like to recognize and encourage contributors who spent time to review, synthesize, think, explain, not just their own code but other people's; code contributions should be compact and concise, and not require huge amounts of our attention to understand and review. (In my opinion, a good code contribution always starts with a good bug/feature.) I also agree with the other opinions expressed on this thread. Julian > On Jun 19, 2026, at 10:34 AM, Alessandro Solimando > <[email protected]> wrote: > > 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 >>
