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