My two cents... 1) What is our criteria for becoming a committer and PMC member? I don't have anything particularly enlightening to say here, and I think I am just reinforcing what we already do, but here goes...
I think this piece from the ASF notes is key for measuring candidacy for committer/PMC status, but still quite subjective: contributions from non-committers - both specific code patches, bugs > reported or commented on, or just helpful interaction on their project > lists - [are used] to evaluate contributors as potential committers It is hard to quantify the value of contributions from non-committers (number of code patches? quality of code patches? number of feature ideas/bugs reported? number of times replied on a dev list thread?). I think we have to consider each candidate on a case-by-case basis with these things in mind. I'm not sure we can fairly create hard and fast rules like a candidate must have filed X tickets and written Y comments. As is pointed out in your third bullet point, we have to decide whether we've gained confidence and trust the contributor to make the right decision when considering things like merging code and PR reviewing. Again, this is all very subjective so I feel it has to be evaluated on a case-by-case basis, which is basically what we have always done. I would love to hear of more objective/quantitative ways of measuring this sort of thing though, if people have ideas. 2) Do we have separate criteria for committers and PMC members (and thus should elect them separately)? I think we should continue to bundle the two. I haven't heard a compelling reason for separating the two, and bundling them simplifies the process somewhat. Ryan On Wed, May 29, 2019 at 10:17 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/ > > >
