Hi everyone, Thanks Jack, for your efforts in the proposed bylaws. This initiative not only provides a valuable foundation but also prompts us to thoroughly examine our current operations and ensure they align with our collective objectives.
An area I like for discussion is the management of proposals within our growing project. As Iceberg expands and gains new functionalities, it's increasingly possible for spec changes to fall under the radar and not gain the necessary traction. Particularly when we're awaiting feedback from specific people. This can drag out the time it takes to merge changes. Utilizing the (72hr) defined deadlines for approvals, and leveraging the lazy majority vote will help combat this, helping to prevent the stalling of projects due to prolonged periods of inactivity or lack of response. Furthermore, the majority vote rule can significantly impact this process. I've noticed that there have been instances where changes were merged and then subsequently reverted due to post-approval disagreements. This raises an important point for our review process and suggests the need for a structured procedure to manage such scenarios effectively to avoid disrupting our workflow. However, I can definitely envision a scenario where the lazy majority can escalate to consensus based on significance of the change. Additionally, incorporating a periodic review process to revisit the processes and their effectiveness would ensure that our methods continue to evolve in line with the project's needs and community feedback. This structured reassessment would help us adapt and refine our processes, ensuring they remain robust and responsive. Thanks, Drew Gallardo On Tue, Jun 25, 2024 at 11:45 AM Russell Spitzer <russell.spit...@gmail.com> wrote: > Thanks for bringing this up Jack. > > I think having more established rules specifically for the project is > probably a good thing to make sure outsiders see a path to becoming more > included in the project. I'm especially interested in the proposals for > more actively including newer contributors from different backgrounds in > the management of the project. I have definitely heard from others that the > project is difficult to approach and it's not especially clear on how one > goes about becoming involved other than "write some code and hope it > gets reviewed." > > I'm definitely more on the cautious side with this sort of thing. I'd > probably prefer we start with a direct copy of the Apache rules we > currently follow and then go one by one through changes. I agree with > others on the list that any changes should have a clear reason why new > rules should be put in place and some measure we can use to judge the > success of that rule. I also am especially worried about the concept of > "active" members of the project, from a logistic perspective it just sounds > like a hassle and I'm not sure we gain much by tracking it. > > I'm still on vacation at the moment so I haven't had too much time to > actually dig into the details here but I'll be on next week for real and > can read through everything and add any feedback I have > > On Tue, Jun 25, 2024 at 12:55 PM Tyler Akidau > <tyler.aki...@snowflake.com.invalid> wrote: > >> 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 >>>>> >>>>
