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 >
