Thanks Jack for raising this, this is quite important to keep healthy of this community.
I agree with Ajantha about the concerns of accumulated proposals and prs, and maybe we should have another thread to discuss about it? On Mon, Jun 24, 2024 at 20:37 Robert Stupp <sn...@snazy.de> wrote: > 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> 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 >> >> >> >> >
