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 >> >
