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
