Micah has a great list there for me. I'm similarly not as interested in the bureaucracy of the project and more interested in actually discussing how we operate from a technical perspective as the community grows.
On Tue, Jul 23, 2024 at 1:01 AM Micah Kornfield <emkornfi...@gmail.com> wrote: > My 2 cents on this topic. I think we are getting bogged down in relatively > minor details/bureaucratic points. This is a reiteration of a previous > recommendation on the topic, but in the interest of making progress here, > I'd propose let's break this conversation down and focus on incremental > definitions/proposals. > > I've added a potential breakdown below. This is roughly ordered from > codifying day to day business, and extends to longer term concerns. I > would aim for minimalism on each of these and add additional guidance when > we need it. It is important to keep in mind that most decisions made on a > day to day basis are fairly easily reversible and more process/formalism > can always be added if some part of the process has bugs in it. > > 1. Requirements to merge a PR (1 committer approval + X amount of time to > allow others to review?) > 2. Requirements major projects/features including spec changes > 3. Define roles/responsibilities and provide guidance on how members can > grow into those roles. (Cover release manager, comitter, PMC member, > community member, with links as appropriate). > 4. Create guidelines on starting new revision to the specification (i.e. > when will the table V3 spec be considered closed?). > 5. People issues (if the community thinks this is still necessary). > > Thanks, > Micah > > On Mon, Jul 22, 2024 at 10:05 AM Jack Ye <yezhao...@gmail.com> wrote: > >> 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 >>>> >>>
