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
