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