Yes I also agree there is the issue of accumulated proposals and PRs. And I think we should discuss it as a part of the bylaw, since the voting process matters a lot regarding the velocity.
For the PR part, my approach in the bylaws is to make sure code modification is a lazy consensus of a committer that is not the author. This is used by multiple other projects, and seems like there is no one against it at this moment. It is a good balance compared to the standard review-and-commit with 3 +1 consensus approval, and a direct commit-and-review that might greatly decrease code quality. The lazy consensus also makes it clear that we trust all committers, and 1 +1 vote of the committer can merge the PR. We do not need to always wait for a specific group of people for each domain to take a look and approve. If there is any disagreement, we can always re-discuss it as a design topic, vote more seriously, and then make fixes accordingly. For the design part, my original draft puts the "accepting a design proposal" vote type to be a lazy majority. I understand that we want to be very careful since Iceberg is a format project, but after all, a spec/standard is something that most people agree on, not something everyone agrees on. When looking into other well-known standards that have clearly-defined RFC processes (e.g. HTTP, Rust, PHP, etc.), they are all majority-voted, where 2/3 majority is used for primary standard updates, lazy majority is used for secondary implementation designs. This avoids the possibility for a small group of people having very strong opinions and continuously blocking the evolution of the standard. I changed it to a consensus approval in the latest draft because of 2 reasons: 1. in a previous devlist thread, we have discussed about this: https://lists.apache.org/thread/p20ypnstcrckyv845hlp01wo0hrqwz6y, and the corresponding PR https://github.com/apache/iceberg/pull/9932 is approved and merged. 2. This matches the general Apache guideline of having consensus approval for code modifications: https://www.apache.org/foundation/voting.html#apache-voting-process However, this decision to use consensus approval is technically not formally voted on devlist. Even though it is approved in PR, it is possible that at that time people were not really thinking about its implications. After all, the definition of "code modification" in Apache is vague, and I don't think there is a requirement to say a proposal is a part of that and stick to the vague standard process. Maybe we should re-discuss this and formally conclude a direction with everyone. Best, Jack Ye On Mon, Jun 24, 2024 at 6:19 AM Renjie Liu <liurenjie2...@gmail.com> wrote: > 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 >>> >>> >>> >>> >>
