Thank you Jack for wrangling this. These conversations are never easy, but I'm glad to see this happening. As a relative newcomer to the Iceberg effort, I am personally supportive of the idea of bylaws. I agree with Ryan that it's important to not overspecify and overindex on processes, but I do think a project that has grown to the size of Iceberg may need to start to function differently from the way it did when it was much smaller if it wants to continue moving forward quickly, effectively, and equitably.
A few of my opinions on some of Jack's points below, take them for what they are worth: 1. I like the idea of guidelines on committership and PMC membership, but worry about overspecification limiting who might be considered. Just something to be careful about. 2. On paper active/inactive/emeritus sounds nice, but if emeritus markers are just advisory from an ASF rules perspective, then what's the point? Just making it clear to an outsider what the active community looks like at any given time? 3. PMC chair rotation: it seems a bit silly to have to consider this when the chair role is largely meant to be an administrative function, but given that the chair in every project I've seen has indeed carried outsized influence as a result, it does seem like a healthy exercise. 5. I personally prefer majority voting rules for an effort the size of Iceberg. The single veto power in consensus votes just makes it too easy for one person to filibuster changes that most of the community would like to see move forward. Beyond a certain point, consensus just isn't practical, IMO. It also motivates folks who care deeply about their -1 to rally support for their position, sharing the burden of influence across both sides of the discussion. With consensus votes, the person who is -1 doesn't have to convince anyone, they can just block, and all of the burden of advocacy falls on the +1s. -Tyler On Tue, Jun 25, 2024 at 10:08 AM Jack Ye <yezhao...@gmail.com> wrote: > Thanks everyone for the insightful comments! I have raised a separate > thread for the initial trimmed down version of the proposal. > > To summarize, here are the discussion points we will have once the initial > version is passed: > 1. guidelines for committership and PMC membership > 2. active, inactive, emeritus status for committers and PMC members > 3. PMC chair rotation > 4. definition of subprojects for releases > 5. design proposal acceptance vote criteria > 6. security related issues reporting and fixes process > 7. commit-and-review for young subprojects > > I will start with topic 1, and discuss these topics one by one. > > Feel free to keep providing comments or feedback in this thread, and > please let me know any additional topics I did not cover in the list above! > > Best, > Jack Ye > > > > > On Tue, Jun 25, 2024 at 8:54 AM Honah J. <hon...@apache.org> wrote: > >> Hi everyone, >> >> Thanks to everyone for the valuable points raised recently. >> >> >> I’m in favor of having bylaws that contain details on how the Iceberg >> community works, especially regarding “Decisions,” as this will provide >> clarity and guidance for all members. I would like to share some of my >> thoughts on this: >> >> >> - +1 on focusing on landing the initial version of the bylaws. >> Starting with what we are doing now is good. Having a foundational set of >> rules in place is essential for moving forward effectively. >> - As others mentioned, the approval process for Design Proposals >> merits further discussion. We might consider distinguishing between design >> proposals for implementation changes (new functionalities, large >> refactoring, etc.) and those for spec/standard changes. Spec/standard >> changes typically require broad agreement, recognizing that complete >> consensus might not always be achievable. >> - +1 on establishing specific criteria/guidelines for Committership >> and PMC membership. Clear guidelines can motivate participants to take on >> more responsibility and serve as a roadmap for new contributors. >> - I also +1 on the idea of PMC chair rotation. Rotating the PMC chair >> annually can help distribute the responsibility more equally among all PMC >> members. >> >> >> I would love to hear others’ feedback and thoughts on this. >> >> >> Best regards, >> >> Honah >> >> On Tue, Jun 25, 2024 at 7:03 AM Xuanwo <xua...@apache.org> wrote: >> >>> Hi, everyone. >>> >>> Thank Jack Ye to start this hard work first. >>> >>> I want to emphasize that ONE being seen as the project leader is not >>> about holding the position of PMC Chair, but rather due to his >>> contributions. >>> >>> I'm more interested in lowering the entry requirements for committers >>> and PMC members than in rotating the PMC chair position. I believe that >>> expanding the number of committers and PMC members will improve community >>> health more effectively than rotating the PMC Chair annually. >>> >>> On Tue, Jun 25, 2024, at 20:49, Rich Bowen wrote: >>> > On 2024/06/24 07:38:47 Jack Ye wrote: >>> >> Hi everyone, >>> >> >>> >> 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 >>> > >>> > Hi, friends. I have made a few comments in the doc. I want to clarify >>> > that I'm *not* speaking here as a board member (and of course >>> directors >>> > cannot, individually, Speak For The Board), but as someone who has >>> been >>> > a community manager for going on 20 years. >>> > >>> > A lot is being written about the (perceived) problems in the project, >>> > and everyone seems to know what you should do about it. I certainly >>> > have my own opinions. But you, not they, are tasked with shepherding >>> > this project. >>> > >>> > I am aware that I'm an outsider, and that I have not earned a voice >>> > here. However, I want to suggest, respectfully, that you intentionally >>> > include an outsider (perhaps/probably not me) in this conversation, >>> > since it can be very challenging for any group to see the solutions to >>> > the problems that they themselves have helped to create. I encourage >>> > you to find someone outside of your community who can have frank >>> > conversations with PMC members - particularly those who are not in the >>> > "ruling class" - about the problems that they perceive, and help steer >>> > the discussion. >>> > >>> > I think that you're heading a good direction with this work, but I am >>> > concerned about a few points, particularly the definition of "active". >>> > Rules around who is "active" are almost always used, in practice, to >>> > amplify the voices of a few, to the detriment of the many. I wrote >>> > about this some here: >>> > https://drbacchus.com/who-are-the-active-maintainers/ >>> > >>> > Many projects, here and elsewhere, set the bar too high in defining >>> who >>> > is "active", who sould be a committer, and who should be a PMC member. >>> > I have always encouraged projects to hand out committer like candy, >>> > because the risk of making someone a committer "too early" is that >>> > you'll have to revert some of their changes, while the risk of making >>> > them a committer too late is that they'll go away and you'll be much >>> > poorer for having missed them. My standard advice to every project is >>> > that any problems you may have, or may be perceived to have, with >>> > neutrality, can and should be solved by inviting more voices to the >>> > conversation, and welcoming committers (especially non-code >>> > committers!), and PMC members, a little earlier than you're entirely >>> > comfortable with. It's not a panacea, but is about as close as we can >>> > get in open source. >>> > >>> > Thanks for doing this hard work. >>> >>> -- >>> Xuanwo >>> >>
