> I would love to have a "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.
Thanks JB for bringing this up. +1 to collect all the problems from the community first by openly discussing it (without targeting individuals) and addressing them through bylaws. - Ajantha On Tue, Jun 25, 2024 at 11:35 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > 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 >> >
