The bottleneck in popular oss projects is typically understanding, not just coding. And this bottleneck is even more amplified in the age of ai coding.
I agree with what Gang said, we encourage contributors not only contributing code, but also high quality code reviews, which helps building trust in the community. On Fri, May 29, 2026 at 2:13 PM Gang Wu <[email protected]> wrote: > Reviewer bandwidth is a scarce resource in almost every open-source > project, and we have experienced similar issues in iceberg-cpp. > > I believe the core challenge is that maintainers are responsible not only > for reviewing code but also for its long-term maintenance after merging. > Consequently, reviewers must invest significant time to thoroughly > understand every aspect of a PR. While adding new reviewers is always > beneficial, it is essential that they demonstrate a deep understanding of > the codebase and a willingness to share this long-term responsibility. This > ensures we can trust their reviews in the future. This approach aligns with > our committer guidelines, which emphasize building trust through consistent > code contributions and quality peer reviews. > > > > On Fri, May 29, 2026 at 1:28 PM Anurag Mantripragada < > [email protected]> wrote: > >> Hi all, >> >> Thanks for bringing this up. >> >> I would like to add that I have experienced similar bottlenecks within >> the Spark connector area, where limited reviewer bandwidth frequently >> delays progress. We have tried to bring committers and contributors >> together via separate syncs >> <https://docs.google.com/document/d/19nno1RoPznbbxKOZZddZNHHafa7XULjbN6RPExdr2n4/edit?tab=t.0#heading=h.r977qio1wsv2> >> for Spark, but we remain bottlenecked. >> >> While I generally agree with the points raised regarding the need to >> increase the number of committers to address these concerns, I believe this >> should not in any way circumvent the qualities and standards described in >> our committer guidelines >> <https://iceberg.apache.org/community/#how-do-i-demonstrate-those-qualities> >> . >> >> I would love to hear what PMC thinks. >> >> ~ Anurag >> >> >> On Thu, May 28, 2026 at 12:51 PM Jared Yu <[email protected]> wrote: >> >>> Hi Jordan, >>> >>> I would also like to thank you for bringing this up to the broader >>> community. I'm currently focusing on contributing to PyIceberg and >>> currently share many of the viewpoints you mentioned. I messaged someone >>> about this before, noting that PyIceberg seems quite bottlenecked by the >>> small handful of people in charge of merging. That person said they could >>> bring up the idea of adding more committers to the project, perhaps that in >>> itself would be a viable option? For Iceberg-Rust, maybe there are some >>> reliable and frequent unofficial reviewers who have been contributing >>> steadily over the past months/years. It would be nice if the community >>> could help nominate them and bring them to the attention of the maintainers >>> so they can potentially be added as committers to help speed up the process >>> of getting the bindings on parity with Java. I think this would greatly >>> help all the current Iceberg bindings. >>> >>> On Thu, May 28, 2026 at 11:29 AM Shawn Chang <[email protected]> >>> wrote: >>> >>>> Hi Jordan, >>>> >>>> Thanks for bringing this to a broader discussion. >>>> >>>> I totally agree that we have a reviewer bottleneck in the iceberg rust >>>> community. This trend seems common across many open source projects, >>>> especially since AI-assisted coding became the norm, while AI-assisted >>>> reviewing doesn’t provide equivalent confidence to project maintainers. >>>> >>>> Outside reviews are always welcome and are usually very helpful. >>>> Personally, I’ve learned a lot from review comments in general, not just >>>> from the Iceberg maintainers. Ultimately, the responsibility for ensuring >>>> code quality falls on the person who clicks the merge button. I’m not sure >>>> if we can address the bottleneck immediately, but I’m very curious to hear >>>> what other members think about it. >>>> >>>> We really want to hear and discuss ideas around the project direction >>>> through multiple channels, including the email thread, slack, GitHub >>>> Discussions, and the rust community syncs. In fact, we just discussed some >>>> of the items you mentioned, such as delete manifest processing support, >>>> during the iceberg rust community sync earlier today. Besides that, we also >>>> discussed adding metadata-level variant support, encryption support, etc., >>>> and I believe these all align with the feature parity goals. >>>> >>>> Looking forward to hearing other thoughts here! >>>> >>>> Best, >>>> Shawn >>>> >>>> On Thu, May 28, 2026 at 9:29 AM Jordan Epstein <[email protected]> >>>> wrote: >>>> >>>>> Happy Thursday, everyone! >>>>> >>>>> I wanted to try and kick off a discussion here regarding seeing what >>>>> we could do about iceberg-rust and increasing the amount of review >>>>> bandwidth there. Obviously, we're constrained to some degree on all of >>>>> the >>>>> iceberg projects but this one is gaining a lot of traction and I've heard >>>>> anecdotally of many projects beginning to maintain their own forks here >>>>> because getting code reviewed is just too much of a challenge. >>>>> >>>>> Given that these projects in other languages are generally just trying >>>>> to achieve feature parity with Java, it really diminishes them when key >>>>> features are missing. >>>>> >>>>> In iceberg-rust, for example: >>>>> - No positional delete writing support >>>>> - No deletion vector writing support >>>>> - No HDFS support >>>>> >>>>> One idea that I have to increase reviewer bandwidth here could be to >>>>> take some key stakeholders from many of the existing OSS rust-based >>>>> iceberg >>>>> projects and add them here? E.g. somebody (trusted) from DataFusion >>>>> (Comet), RisingWave, DataBend, Polars. Perhaps there are also some major >>>>> companies in the space that might like representatives (for example I see >>>>> Amazon, Microsoft, Apple, Palantir in there). Then that person could at >>>>> least be the point-person for reviews that are necessary for features in >>>>> those upstream codebases. To be clear, I'm mainly suggesting that these >>>>> people are given mandates to review changes to get these projects to >>>>> parity >>>>> with the Java versions, and less so focusing on bespoke features specific >>>>> to one language. >>>>> >>>>> I understand that we want all would-be contributors to review as well, >>>>> but I can come up with a few examples where a change is reviewed >>>>> adequately >>>>> by somebody that lacks permissions, and then it eventually goes idle since >>>>> nobody can supply the approval. >>>>> >>>>> Let me know what you think! Thank you! >>>>> >>>>> Best, >>>>> Jordan Epstein (IMC Trading) >>>>> >>>> >>> >>> -- >>> Best regards, >>> >>> Jared Yu >>> B.S. Statistics - University of California, Davis '19 >>> M.S. Data Science - Johns Hopkins University '22 >>> >>
