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 >
