A 6-month waiting period from committer to PMC is tempting because it’s easy to implement, but as you described it yourself, it is arbitrary, which ultimately de-values what it means to be a member of the Geode PMC.
The bottom of https://www.apache.org/foundation/voting.html explains why The Apache Way favors voting over authority figures, rules, or processes: "None of these tend to be very good substitutes for doing the hard work of resolving the conflict”. If we could perfectly enumerate objective criteria to be a committer or PCM member, there would be no need to vote: just make sure all the boxes are checked. That isn’t the Apache way. I feel that our existing procedures for discussing and voting work fine, even without well-defined criteria. As I outlined in another branch of this thread, the only real requirement for committer (or PMC) is trust, and I believe voting is the best way to reach consensus on when trust has been earned. -Owen > On May 29, 2019, at 12:04 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > A few observations I have found by looking through the Apache wiki for all > the projects is: > That several of them do separate the two roles. > The discussions about committers happens in the dev@ list while discussions > for PMC happen on the private@ list. > Some projects projects treat PMC as a promotion role for someone that has > been successful at the committer role, but with no clear definition of > success or timeline. > > Maybe a starting point we just set some arbitrary period of time, say 6 > months, after becoming a committer where someone on the PMC can nominate a > committer for a promotion to the PMC. If within this time the committer as > continued to show increasing merit then the PMC’s should vote positively. > > Then we are just left with coming up with clear metrics for measuring merit > as a contributor to become a committer. I think the The Apache Way Merit > definition is pretty clear in its distinction of what is and isn’t considered > merit. The key things I see is that employment is not considered in the > merit, nor is future or vapor works. Merit must only be ranted for things > that have been completed and measured by its impact. > > Personally, I think we need to look at more than just code contributions. We > also need to look at process and community. By process I think they should be > able to submit a PR, respond to feedback on the submission, and see the PR > through to merge. They should also be commenting and providing clear > actionable feedback on other’s PRs. For community I think they need to be > actively participating in user@ and dev@ discussions. Additionally I feel > that in all these forums they need to adhere to our code of conduct, which we > should also attempt to solidify. The bottom line is that if we accept this > person as a committer what will they bring to the community beyond their > ability to produce some code. > > Perhaps then the PMC role is more about amplifying those that excel at these > things and mentors others in them. > > Apache Felix has a pretty good page we could use as a starting point for > outlining our process. > https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Community+Roles+and+Processes > > <https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Community+Roles+and+Processes> > > >> On May 29, 2019, at 10:13 AM, Anthony Baker <aba...@pivotal.io> wrote: >> >> I think it’s time to re-establish consensus around two things: >> >> 1) What is our criteria for becoming a committer and PMC member? >> 2) Do we have separate criteria for committers and PMC members (and thus >> should elect them separately)? >> >> The ASF notes that projects are free to chose the approach that works best >> for them [1]: >> >>> PMCs are free to set the bar for merit within their projects, as long as >>> decision making is done in a collaborative fashion as in the Apache Way. >>> Healthy PMCs will regularly review contributions from non-committers - both >>> specific code patches, bugs reported or commented on, or just helpful >>> interaction on their project lists - to evaluate contributors as potential >>> committers. Ensuring that PMC members are helping to mentor helpful new >>> contributors to their projects helps to ensure a healthy and growing >>> project community. >>> >>> PMCs vary significantly in the level of commitment and work expected to be >>> considered for a committership. Some PMCs vote in new PMC members typically >>> from their existing committers (i.e. the progression is contributor -> vote >>> -> committer -> vote -> PMC), while other PMCs always elect new committers >>> into the PMC simultaneously (contributor -> vote -> committer & PMC member). >> >> To date, we’ve been mostly following the “bundling” approach of combining >> committers / PMC’s votes. This is not explicitly spelled out in our wiki >> however (see [2][3]). We established the current criteria back in 2016 >> [4]. The private@ thread [5] that spawned this discussion included some >> great advice from our project mentors (Roman, Kos, Niall, William Rowe). If >> I can summarize it here, it basically boils down to: >> >> - Set the bar for inclusion as low as possible >> - Read the definition of Merit [5] >> - Is the person trustworthy with code, community, etc. >> >> Thoughts? >> >> >> Anthony >> >> >> [1] https://apache.org/foundation/governance/pmcs.html >> [2] https://cwiki.apache.org/confluence/display/GEODE/Becoming+a+committer >> [3] >> https://cwiki.apache.org/confluence/display/GEODE/Nominating+a+Committer+and+PMC+Member >> [4] >> https://lists.apache.org/thread.html/819a140349394833cf1c51b653672ab7a950d48891cf6abef245b8a7@1452130249@%3Cdev.geode.apache.org%3E >> [5] http://theapacheway.com/merit/ >> >> >
