I don’t see a compelling reason for Geode to make a distinction between committer and PMC member.
If you have the power to merge PRs, you are a steward of the codebase; we need to be able to trust that you have Geode’s best interests at heart and will adhere to our practices. PMC membership confers the additional benefit of voting rights on releases and new committers. To me, the requirements are no different; we need to be able to trust that you have Geode’s best interests at heart and will adhere to our practices. If the idea is to restrict the PMC to a smaller set of “gatekeepers" to ensure we don’t make a release containing a bad commit, that implies that we don’t actually trust committers (or that being both a committer and a PMC member could somehow be a conflict of interest). Let’s keep things simple and extend trust and voting rights at the same time, or not at all. -Owen > On May 29, 2019, at 1:19 PM, Ryan McMahon <mcmellaw...@apache.org> wrote: > > 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/ >> >> >>
