Hi, Just a couple of comments and prevision from ASF standpoint:
1. Generally speaking, I like this bylaws proposal, and I don't see a problem to state again what is defined at ASF level (I'm thinking about vote which is described here https://www.apache.org/foundation/voting. As reminder, it's not possible to veto a release vote, it is possible to vote a code modification vote. As soon as the bylaws proposal contains references to the ASF guidelines, it's fine imho. Even if it's a bit covered in the proposal, I would love to have "problems statement" as introduction: what problems we see concretely (and with facts to prove that), what are the proposals in the bylaws to fix that. 2. About inactive/emeritus PMC status, I would like to clarify: if the PMC members want to identify inactive/emeritus status in their roster, they can, but it won't change the actual role/power of the PMC member (inactive/emeritus PMC status doesn't exist at ASF and the PMC members are appointed by the ASF). The PMC Chair of a project can remove PMC members by submitting a resolution to the board. Only the board can actually remove PMC members from a project. So, no problem if you want to have inactive/emeritus status, but an inactive/emeritus PMC member can come and vote for release (and the vote will be binding) or another project decision. 3. The reason why I think a private discussion would have been good (before going on the dev mailing list) is because, in the brief "problems statement", we have some PMC members referenced with their affiliation ("In light of the recent change of company for a few committers and PMC members"). I have the feeling that it goes into "pre-agreement discussions with third parties that require confidentiality". So I guess the discussion on the private mailing list was to request an review from PMC members and a pre-agreement (maybe with required change in a couple of sentences) to go on the dev mailing list. Without the "in-light" sentence, no problem to go directly to the dev mailing list. Also, as this proposal is about the project governance, which is the responsibility of the PMC members, even if it's good to have community feedback, the PMC members will decide at the end of the day :) Thanks Jack, I will do a pass on the doc to leave my comments. Regards JB On Mon, Jun 24, 2024 at 8:33 PM Carl Steinbach <c...@apache.org> wrote: > > + private for PMC members who may not follow dev > > 1/ I encourage the folks who have already responded on the private@ thread to > replay their comments here. As I noted earlier, this discussion falls outside > the categories that belong on the private list. > > 2/ I think adopting a set of clearly articulated bylaws and a process for > amending them is a net good for the Iceberg community. > > 3/ Regarding the overlap between the proposed bylaws and other ASF documents, > having all of the rules in one place reduces the potential for confusion and > also makes it easier for outsiders to understand how the project actually > works. > > 4/ Regarding automatic emeritus status for committers and PMC members, it's > been my experience on other Apache projects that having bylaws is pointless > if the PMC can't achieve the necessary quorums for voting and that this > becomes unavoidable as the project ages and the size of the PMC increases. As > long as it's easy for emeritus PMC/commmitters to reinstate themselves, I > don't see any harm in the proposed rules for automatic emeritus status. > > 5/ As someone who firmly believes that Iceberg should have project bylaws, > I'm concerned that it may be hard to reach a consensus on the current > proposal because of its length and the inclusion of several provisions that > address situations that have yet to be encountered by this community. While > it may lead to more work, we're more likely to succeed if we focus first on > adopting a paired-down set of bylaws that includes a clearly defined process > for amending them in the future. > > Thanks. > > - Carl > > On Mon, Jun 24, 2024 at 12:44 PM Jack Ye <yezhao...@gmail.com> wrote: >> >> Thanks for pointing to the ASF guidelines Carl, I did not know that. I had >> the impression of engaging with the private list first due to responses in >> previous devlist discussions, but I guess I landed in the right place >> eventually :) >> >> > In light of the recent change of company for a few committers and PMC >> > members >> Sorry that is probably my wrong use of the word "in light". I just mean this >> event creates a good opportunity for opening this bylaws discussion. I >> didn't mean at all to have bylaws specifically for speculating and >> restricting a few specific people. I think bylaw is something essential as >> the project grows larger and more participants are involved in the community. >> >> -Jack >> >> >> >> On Mon, Jun 24, 2024 at 9:37 AM Ryan Blue <b...@databricks.com.invalid> >> wrote: >>> >>> The motivation for bylaws was this: "In light of the recent change of >>> company for a few committers and PMC members". >>> >>> That means that we're talking about new rules based on what a few specific >>> people might do. Speculation like that belongs on a private list, just like >>> discussing actual behavior would. While no individual was singled out, it's >>> clear who these committers and PMC members are. >>> >>> On Mon, Jun 24, 2024 at 9:30 AM J G <jgreene1...@gmail.com> wrote: >>>> >>>> > The reason for that is that there's a long-standing norm to discuss the >>>> > conduct of individuals only on private lists. In this case, I think it >>>> > applies even though it is discussing hypothetical conduct. And note that >>>> > I'm one of the individuals here. >>>> >>>> Respectfully, what does this mean, Ryan? No individual was even singled >>>> out here. This comes off as stifling discussion, not cool... >>>> >>>> On Mon, Jun 24, 2024, 9:08 AM Jack Ye <yezhao...@gmail.com> wrote: >>>>> >>>>> Sorry for the confusion Ryan, this is not mistakenly sent to devlist. As >>>>> we discussed, this is the thread for collecting community feedback, which >>>>> is essential for forming bylaws with the community. >>>>> >>>>> We have that separated discussion thread in the private list, which we >>>>> will continue to iterate, and the vote will eventually be carried out in >>>>> the private list as you said, according to the ASF guideline. >>>>> >>>>> -Jack >>>>> >>>>> On Mon, Jun 24, 2024 at 8:59 AM Ryan Blue <b...@databricks.com.invalid> >>>>> wrote: >>>>>> >>>>>> Hey everyone, I think Jack mistakenly sent this to the dev list so >>>>>> please let's pause discussion for now. >>>>>> >>>>>> There's a thread on the private list about this in which PMC members, >>>>>> including me, have asked to keep it on the private list right now. >>>>>> >>>>>> The reason for that is that there's a long-standing norm to discuss the >>>>>> conduct of individuals only on private lists. In this case, I think it >>>>>> applies even though it is discussing hypothetical conduct. And note that >>>>>> I'm one of the individuals here. >>>>>> >>>>>> I know that there are also things here that merit discussion (like how >>>>>> to get PRs moving faster), but right now they are all tied up in a >>>>>> bundle of proposed bylaws. I've asked on the PMC list to separate the >>>>>> concerns and to discuss these issues individually. We will follow up >>>>>> with more discussion on this list. >>>>>> >>>>>> Ryan >>>>>> >>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ryan Blue >>>>>> Databricks >>> >>> >>> >>> -- >>> Ryan Blue >>> Databricks
