I meant precision (not prevision) :) Typo mistake :) Regards JB
Le mar. 25 juin 2024 à 07:53, Jean-Baptiste Onofré <j...@nanthrax.net> a écrit : > 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 >
