Another thing that has come up is putting together a committer requirements/guidelines doc. I think it would be great to have a discussion about how we want to do that. Specifically, I'm against adding requirements for new committers (such as time-based minimums or recency requirements) that exclude people from consideration. I think it would be helpful to clarify the path to becoming a committer, though. To me, it's about building trust and that trust is recognized by a PMC vote.
Ryan On Fri, Jul 19, 2024 at 11:00 AM Owen O'Malley <owen.omal...@gmail.com> wrote: > I meant specifically the discussion of the standard roles (eg. users, > committers, pmc, pmc chair) that are well covered in > https://www.apache.org/foundation/how-it-works/#roles > > .. Owen > > On Fri, Jul 19, 2024 at 10:43 AM Jack Ye <yezhao...@gmail.com> wrote: > >> Thank you Owen for moving this forward, we heard you were sick, hope you >> are fully recovered now! >> >> One point regarding "referring to the Apache documentation": I am totally >> for that, but during the initial investigation, I found out that the Apache >> documentations are scattered around, and also have conflicting information. >> >> For example, regarding a "vote for committer or PMC member": >> - this new committer doc [1] writes that "A positive result is achieved >> by Consensus Approval: at least 3 +1 votes and no vetoes." >> - the Apache voting process doc [2] writes that "Votes on procedural >> issues follow the common format of majority rule unless otherwise stated.", >> and when consulting a few Apache members, most of them consider voting for >> committer or PMC member a procedural issue. >> >> Similar situations were found for other topics like description of roles >> and responsibilities, code modification, etc. >> >> I think it is a great chance for ASF in general to consolidate these >> information, especially for matters that have common guidelines in ASF that >> should be adhered to by all projects. With that, we can figure out what to >> put in the Iceberg specific bylaws, either to directly refer to ASF >> official information, or to add additional information and guidelines. >> >> Regarding sub-projects, the main reason I proposed it at the beginning >> was to allow a proper definition of release manager responsibility, since >> each sub-project is released independently. It was not intended to be tied >> to committer responsibilities. >> >> Best, >> Jack Ye >> >> [1] https://community.apache.org/newcommitter.html >> [2] https://www.apache.org/foundation/voting >> >> On Fri, Jul 19, 2024 at 10:22 AM Owen O'Malley <owen.omal...@gmail.com> >> wrote: >> >>> Everyone is welcome to vote. The Iceberg PMC will have the only binding >>> votes. >>> >>> .. Owen >>> >>> On Jul 19, 2024, at 10:19, Wing Yew Poon <wyp...@cloudera.com.invalid> >>> wrote: >>> >>> >>> Hi Owen, >>> Thanks for doing this. >>> Once you have the questions and choices, who gets to vote on them? >>> - Wing Yew >>> >>> >>> On Fri, Jul 19, 2024 at 10:07 AM Owen O'Malley <owen.omal...@gmail.com> >>> wrote: >>> >>>> All, >>>> Sorry for the long pause on bylaws discussion. It was a result of >>>> wanting to avoid the long US holiday week (July 4th) and my >>>> procrastination, which was furthered by a side conversation that asked me >>>> to consider how to move forward in an Apache way. >>>> I'd like to thank Jack for moving this to this point. One concern >>>> that I had was there were lots of discussions and decisions that were being >>>> made off of our email lists, which isn't the way that Apache should work. >>>> For finishing this off, I'd like to come up with a set of questions >>>> that should be answered by multiple choice questions and then use single >>>> transferable vote (STV) to resolve them. STV just means that each person >>>> lists their choices in a ranked order with a formal way to resolve how the >>>> votes work. >>>> The questions that I have heard so far are: >>>> >>>> 1. Should the PMC chair be term-limited and if so, what is the >>>> period? *In my experience, this isn't necessary in most projects >>>> and is often ignored. In Hadoop, Chris Douglas was a great chair and >>>> held >>>> it for 5 years in spite of the 1 year limit.* >>>> 1. No term limit >>>> 2. 1 year >>>> 3. 2 year >>>> 2. What should the minimum voting period be?* I'd suggest 3 days is >>>> far better as long as it isn't abused by holding important votes over >>>> holiday weekends.* >>>> 1. 3 days (72 hours) >>>> 2. 7 days >>>> 3. Should we keep the section on roles or just reference the Apache >>>> documentation >>>> <https://www.apache.org/foundation/how-it-works/#roles>. *I'd >>>> suggest that we reference the Apache documentation.* >>>> 4. I'd like to include a couple sentences about the different hats >>>> at Apache and that votes should be for the benefit of the project and >>>> not >>>> our employers. >>>> 5. I'd like to propose that we include text to formally include >>>> censor and potential removal for disclosing sensitive information from >>>> the >>>> private list. >>>> 6. I'd like to propose branch committers. It has helped Hadoop a >>>> lot to enable people to work on development branches for large features >>>> before they are given general committership. It is better to have the >>>> branch work done at Apache and be visible than having large branches >>>> come >>>> in late in the project. >>>> 7. Requirements for each topic (each could be consensus, lazy >>>> consensus, lazy majority, lazy 2/3's) >>>> 1. Add committer >>>> 2. Remove committer >>>> 3. Add PMC >>>> 4. Remove PMC >>>> 5. Accept design proposal >>>> 6. Add subproject >>>> 7. Remove subproject >>>> 8. Release (can't be lazy consensus) >>>> 9. Modifying bylaws >>>> >>>> Thoughts? Missing questions? >>>> >>>> .. Owen >>>> >>> -- Ryan Blue Databricks
