Just to follow up on the other topics, here are my comments, mainly to reconcile with what have been discussed in different threads, which could help formulating these multiple-choice questions:
> What should the minimum voting period be? Do we decide a minimum voting period for all topics, or do we decide a different period for each topic? So far it seems like the ASF convention has different minimum periods defined, like 3 days for release [1], 7 days for new committers/PMC members [2]. > 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. > I'd like to propose that we include text to formally include censor and potential removal for disclosing sensitive information from the private list. Personally I am definitely +1 for this, but going back to the topic of Iceberg vs ASF bylaws/guidelines, I feel ideally this should also be a part of ASF general bylaws/guidelines that Iceberg simply just references. > Requirements for each topic I think this is also missing code modification and the improvement proposal votes. My impression so far after discussions in the initial bylaws doc [3] is that ASF definition of "code modification" is closer to a full design process and uses consensus approval. But in reality "merging PR" is a much more lightweight "vote" that typically requires just 1 committer approval of the PR. On the other hand, the Iceberg improvement proposal process is currently described to use the code modification consensus approval vote [4], but there are other options like 2/3 majority and majority vote that were proposed. > consensus, lazy consensus, lazy majority, lazy 2/3's In the initial bylaws doc [3] it was pointed out that the definition of "lazy consensus" is different in different documents. In general the definition is "no -1", but there is also the definition [5] of "at least 1 +1, no -1". I ended up giving it a different name of "minimum consensus", and actually this has been the model used for merging pull requests. We might want to clarify that part first before voting for these options. [1] https://www.apache.org/legal/release-policy.html#release-approval [2] https://community.apache.org/newcommitter.html#discussion [3] https://docs.google.com/document/d/1S3igb5NqSlYE3dq_qRsP3X2gwhe54fx-Sxq5hqyOe6I/edit [4] https://iceberg.apache.org/contribute/#how-are-proposals-adopted [5] https://orc.apache.org/develop/bylaws/ -Jack On Fri, Jul 19, 2024 at 2:29 PM Jack Ye <yezhao...@gmail.com> wrote: > > specifically the discussion of the standard roles > > Yes, there are also other places with different definitions. For example > the default project guideline [1] has additional description of the PMC > member and chair responsibilities. There are a few other places like ASF > glossary [2] where these terms are defined, I cannot recall on the top of > my head, but I can try to dig those up later. > > > putting together a committer requirements/guidelines doc > > +1. For some context, the committer guideline discussion came from both > some initial feedback on devlist, as well as comments in the roles and > responsibilities section. > > Because I initially used the definition of Hadoop bylaws [3] for > committers, which writes: "The project’s Committers are responsible for the > project’s technical management." There were then multiple people pointing > out that committers are not necessarily technical. If we look into the > current definition in the link Owen provided: "A committer is a developer > who has write access to the code repository and has a signed CLA on file. > They have an apache.org mail address. Not needing to depend on other > people to make patches to the code or documentation, they are actually > making short-term decisions for the project." And in ASF Glossarsy: "An > individual who has the privilege to directly commit changes to an Apache > codebase (commit access)." > > Indeed it does not have a requirement for committers to be technical, but > it is arguably still centered around the right to commit code and merge > patches. And that sparked all the discussions of what exactly a committer > means, what are the criteria, do we limit committer rights to commit to > just sub-project, what about people that do not contribute code, etc. I > don't know if there could be a better definition though, maybe we could > discuss that in a separate thread that is visible to more Apache members > and people in other projects. > > I later raised the thread > https://lists.apache.org/thread/4fykr8316cw9lhvgq168tx5yj9zy7gc3 where > you can find more details about the discussions in the thread as well as in > the linked Google doc for committer guideline. Topics like minimum time > requirement and recency requirements were discussed there. Personally, I > included all those aspects in the draft because my main goal is to have an > open discussion about these topics so that we can potentially reach some > consensus, and eventually form a clear guideline. It would be nice if we > can do that as a part of this process and also moderated in the same way. > > -Jack > > [1] > https://cwiki.apache.org/confluence/display/INCUBATOR/Default+Project+Guidelines > [2] https://www.apache.org/foundation/glossary > [3] https://hadoop.apache.org/bylaws.html > > > On Fri, Jul 19, 2024 at 11:54 AM Ryan Blue <b...@databricks.com.invalid> > wrote: > >> 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 >> >
