Thanks Jack for the proposal. I’m generally +1 on this. There are a few details to clarify, but I suspect nothing that’s controversial.
> On 24. Jun 2024, at 12:45, Ajantha Bhat <ajanthab...@gmail.com> wrote: > > Thank you, Jack, for your diligent work on this. > > This seems essential at the moment. > > I would like to address a couple of additional points that need our attention: > > Criteria for Committership/PMC: > We've observed an inconsistency in how committership is granted. Contributors > to sub-projects often attain committership to the main project more readily, > while some who contribute significantly to the main project remain > unrecognized. Although defining explicit criteria is challenging, it might be > beneficial to establish guidelines or metrics that highlight the impact and > quality of contributions. This could encourage more balanced and motivated > participation across all project areas. > > Accumulation of Proposals and PRs: > We have several proposals and PRs that are currently stalled despite multiple > pings. Examples include the partition stats PR and proposals like table > profitability, multi table transaction, secondary indexing etc. These > important contributions are not making the expected progress. It might be > helpful to create bylaws or procedures to ensure these proposals and PRs > receive the necessary attention and are addressed promptly. This could > involve setting timeframes for reviews or establishing a prioritization > process. > > Thoughts and feedback on these suggestions would be highly valuable. > > - Ajantha > > On Mon, Jun 24, 2024 at 1:09 PM Jack Ye <yezhao...@gmail.com > <mailto:yezhao...@gmail.com>> wrote: >> Hi everyone, >> >> In light of the recent change of company for a few committers and PMC >> members, I hear an increasing ask from the community to define proper >> processes in Iceberg to ensure its vendor neutral stance. >> >> I propose that we put up a bylaws document like other projects such as >> Apache Hadoop and Apache ORC. I think this will put people at peace and >> remove many people's concerns about the future of the project and its >> vendor-neutral stance. >> >> Here is a document that I have drafted that can be used as the starting >> point (mostly just copied from the Hadoop one): >> https://docs.google.com/document/d/1BVHbshE2dmCH8QzkeMd9PQdJ86_slavDy1YPueqNSgI/edit >> >> This proposal is currently undergoing review by the PMC. At the same time, >> it is critical to also understand the feedback from the community so that we >> can formulate the bylaws in a way that meets the community's needs. >> >> As a guide, here are a few key points that I think is worth special >> attention and everyone's opinion: >> >> 0. Bylaws or not: first and foremost, do we think such bylaws would be >> helpful, or do we think this is too much? >> >> 1. Emeritus status: the bylaws introduce the concept of emeritus committers >> and PMC members, and will mark inactive committers and PMC members as >> emeritus. It is designed purely for information purposes, so it is easier to >> know who to count for during a vote. For people that have questions >> regarding the PMC members' vendor affiliations, they can use this >> information to find out details about the proportion of active PMC members >> in each organization. The emeritus status will not remove rights of the >> specific committers or PMC members, and anyone who would like to re-join the >> community just needs to report to PMC with an email to remove the status. >> >> 2. PMC chair rotation: the bylaws introduce an annual rotation of the PMC >> chair. The chair is purely an administrative role that does not have special >> power, but it is undeniable that the chair is usually seen as the lead of >> the project from a public perspective. By further rotating this role, it >> makes it clear that no one in the PMC is specifically leading the project >> direction, and the PMC as a whole manages the direction of Iceberg. Given >> that right now at least 10 PMC members are fully salaried workers dedicated >> to the Iceberg project, the overhead seems acceptable to perform rotations. >> >> 3. Definition of subprojects: the bylaws divide the project into >> subprojects, in order to properly define the responsibility of a release >> manager. This is a concept learned from projects like Hadoop, and I think as >> Iceberg is growing a lot in scope, this division will also help us formalize >> different modules of the project, and properly release components like the >> table format spec, catalog spec, etc. that can be used for consumption >> without dependency on releasing language-specific libraries. >> >> 4. Voting procedure: the bylaws describe a lot about the voting procedure, >> and how different matters in Iceberg should be voted. I mostly referenced >> other projects when writing the related sections, so it would be great for >> us to double check it with existing decisions that have been made in Iceberg >> regarding voting, as well as related rules in ASF to avoid any conflict. >> >> Really appreciate any feedback, and look forward to discussing this with >> everyone! >> >> Best, >> Jack Ye >> >> >>
