I agree with Micah as well. I also don't want to get bogged down in bureaucracy and more rules inevitably lead to more bureaucracy. I also like the prioritization he suggests.
I also think it's important to clarify that this thread isn't trying to rehash the previous threads in a new place. I think Owen's intent is to gather a list of topics and then discuss each topic individually. That's in line with suggestions like Micah's, which have been echoed by other PMC members (and also ASF members). Let's gather topics, figure out whether we need to add a bylaw and discuss each one individually. On Tue, Jul 23, 2024 at 7:45 AM Russell Spitzer <russell.spit...@gmail.com> wrote: > 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 >>>>> >>>> -- Ryan Blue Databricks
