Welcome!

We're glad that you're interested in joining the Apache Iceberg community! Read along to learn how to connect with existing community members and where you can get involved with the project, both technically and socially.

Join the Discussion

Community discussions happen across various mailing lists, on the apache-iceberg Slack workspace, and on specific GitHub issues.

Mailing Lists

Apache Iceberg mailing lists:

Developers: [email protected] -- Iceberg community discussions
Commits: [email protected] -- GitHub commit notifications
Issues: [email protected] -- GitHub issue tracking
CI Jobs: [email protected] -- GitHub Actions notifications
Private: [email protected] -- private mailing list for the PMC to discuss sensitive issues related to the health of the project
- Archive (PMC-only access)

Slack

We use the Apache Iceberg workspace on Slack. To be invited, follow this invite link.

Please note that this link may occasionally break when Slack does an upgrade. If you encounter problems using it, please let us know by sending an email to [email protected].

Requesting Slack Integrations

To request a new app or integration for the Apache Iceberg Slack workspace, send an email to the dev mailing list with the following information:

What you want to add — The name and description of the app or integration
Why you want to add it — The benefit it provides to the community
What permissions does it need — The access levels and permissions required by the app

This allows the community to do a quick consensus check before the app is installed.

Issues

Apache Iceberg tracks issues in GitHub and prefers to receive contributions as pull requests. Issues are tracked in GitHub:

Looking to contribute to Apache Iceberg? See Contributing for more details on how to get started.

Connect with Community Events

The Apache Iceberg community regularly meets for technical discussion both in-person and virtually.

Apache Iceberg Community Calendar

The community maintains two calendar feeds:

Iceberg Dev Events{:target="_blank"}: A shared calendar for all Iceberg development syncs, including the triweekly community sync, subproject syncs for Python, Rust, and Go, the Iceberg Catalog Community Sync, and other ad hoc syncs the community may want to schedule or discuss.
Iceberg Community Events{:target="_blank"}: Events such as conferences and meetups, aimed to educate and inspire Iceberg users.

Hosting an Apache Iceberg Meetup

Meetups related to the Apache Iceberg project are held around the globe thanks to community volunteers. Interested individuals are encouraged to host community meetups using the name Apache Iceberg Meetup <geographical location> in compliance with Apache Software Foundation's branding and trademarks guidelines. No explicit PMC approval is required.

Hosts are required to ensure that:

The Apache Iceberg ecosystem should be championed in every meetup and technical session
All talks should be vendor-neutral and not sales pitches
Each meetup should have at least two talks with speakers representing different companies/organizations
Planned meetups ought to be brought to the attention of the dev list
All Community Guidelines must be respected

Meetups must be small events under the ASF branding guidelines and are typically small, informal gatherings. If you're unsure whether an event is a meetup, meetups usually:

Rely on a curated selection of talks, where organizers work with the community to include a diverse representation of speakers, topics, and companies. Due to the small number of submissions, meetups might use, but don't require, a CfP.
Are single-tracked and accommodate only a handful of sessions.
Have at most 2-3 hours of content, plus networking time.
Are sponsored by 1-3 companies providing food, drinks, or meeting space; not by selling booth space or marketing opportunities. They don't require substantial financial support.

If you don't know whether an event qualifies as a meetup, please ask the PMC through the private mailing list! (Be sure to do this before using the Apache Iceberg brand or trademark.)

Community Guidelines

Apache Iceberg Community Guidelines

The Apache Iceberg community is built on the principles described in the Apache Way and all who engage with the community are expected to be respectful, open, come with the best interests of the community in mind, and abide by the Apache Software Foundation Code of Conduct.

More information specific to the Apache Iceberg community is in the next section, the Path from Contributor to Committer.

Participants with Corporate Interests

A wide range of corporate entities have interests that overlap in both features and frameworks related to Iceberg and while we encourage engagement and contributions, the community is not a venue for marketing, solicitation, or recruitment.

Any vendor who wants to participate in the Apache Iceberg community Slack workspace should create a dedicated vendor channel for their organization prefixed by vendor-.

This space can be used to discuss features and integration with Iceberg related to the vendor offering. This space should not be used to promote competing vendor products/services or disparage other vendor offerings. Discussion should be focused on questions asked by the community and not to expand/introduce/redirect users to alternate offerings.

Marketing / Solicitation / Recruiting

The Apache Iceberg community is a space for everyone to operate free of influence. The development lists, slack workspace, and github should not be used to market products or services. Solicitation or overt promotion should not be performed in common channels or through direct messages.

Recruitment of community members should not be conducted through direct messages or community channels, but opportunities related to contributing to or using Iceberg can be posted to the #jobs channel.

For questions regarding any of the guidelines above, please contact a PMC member.

The Path from Contributor to Committer

Many contributors have questions about how to become a committer. This section outlines what committers do and how they are invited.

What are the responsibilities of a committer?

In the Iceberg project, committers are community members that can review and commit changes to Iceberg repositories. Reviewing is the primary responsibility of committers.

How are new committers added?

Starting from the foundation guidelines, committers are nominated and discussed by the PMC, which uses a consensus vote to confirm a new committer. This vote is the only formal requirement in the Iceberg community — there are no other requirements, such as a minimum period of time or a minimum number of contributions. Similarly, there is no length of time or number of commits that automatically qualify someone to be a committer.

Committers are added when someone has built trust with PMC members that they have good judgment and are a reliable reviewer.

What does the PMC look for?

PMC members typically look for candidates to have demonstrated a few qualities:

Conduct — Committers are representatives of the project and are expected to follow the ASF Code of Conduct.
Judgment — Committers should know the areas where they are qualified to evaluate a change and when to bring in other opinions.
Quality — Personal contributions are a strong signal. Contributions that don’t require major help demonstrate the context and understanding needed to reliably review changes from others. If a contributor often needs guidance, they are probably not ready to guide others.
Consistency — Reviewing is the primary responsibility of a committer. A committer should demonstrate they will consistently apply their context and understanding to help contributors get changes in and ensure those changes are high quality.

How do I demonstrate those qualities?

To be a committer, a candidate should act like a committer so that PMC members can evaluate the qualities above. PMC members will ask questions like these:

Has the candidate been a good representative of the project in mailing lists, Slack, github, and other discussion forums?
Has the candidate followed the ASF Code of Conduct when working with others?
Has the candidate made independent material contributions to the community that show expertise?
Have the candidate’s contributions been stable and maintainable?
Has the candidate’s work required extensive review or significant refactoring due to misunderstandings of the project’s objectives?
Does the candidate apply the standards and conventions of the project by following existing patterns and using already included libraries?
Has the candidate participated in design discussions for new features?
Has the candidate asked for help when reviewing changes outside their area of expertise?
How diverse are the contributors that the candidate reviewed?
Does the candidate raise potentially problematic changes to the dev list?

How can I be a committer?

You can always reach out to PMC members for feedback and guidance if you have questions.

There is no single path to becoming a committer. For example, people contributing to Python are often implicitly trusted not to start reviewing changes to other languages. Similarly, some areas of a project require more context than others.

Keep in mind that it’s best not to compare your contributions to others. Instead, focus on demonstrating quality and judgment.

How many contributions does it take to become a committer?

The number of contributions is not what matters — the quality of those contributions (including reviews!) is what demonstrates that a contributor is ready to be a committer.

You can always reach out to PMC members directly or using [email protected] for feedback and guidance if you have questions.