I appreciate the concern about bias/cronyism. If having some criteria will “level the playing field”, then let’s discuss what those criteria would be.
However, in voting for a committer, a single -1 carries more weight than all the +1’s in the world. A -1 also requires explanation. This system of checks and balances should be sufficient to combat most implicit bias or voting blocs. If it looks like someone is getting +1 votes for the wrong reasons, it only takes one person to call it out by casting a -1. If you have a reservation, don’t be afraid to speak up! Keep in mind what we are voting for when we make someone a committer. We are not voting “have they satisfied this or that”. We are voting “can we trust them to be a good steward of the codebase”. Apache’s guidelines are intentionally vague, because to be any more specific risks applying an artificial definition of “trust”. Suggesting some signals a voter might take into account to judge trustworthiness is very different from prescribing an explicit metric that every voter must use. If we want to go that route, let's follow the DMV model and give each prospective committer a multiple-choice test about Geode which they must score 80% or higher to earn their “license to commit”. If they fail the test, they must wait 90 days before they can retake it. I think it might be helpful to first define clearly what code of conduct a committer is expected to follow. That exercise would help frame exactly what we are trusting new (and existing) committers to adhere to. It might also be useful to consider making it policy to suspend committer status if expected code of conduct is not adhered to, like a DUI. In this commit-then-review model, the bar to becoming a committer could be lower, but followed up with continuing mentorship. -Owen > On May 30, 2019, at 10:23 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > The major concern I have with voting without guidelines is that this process > has been vary biased towards fellow employees. Internal knowledge and trust > is being used to evaluate each candidate. Some have had very little public > interaction with the community as a whole. I think it's important that we > have guidelines to avoid this implicit bias we have for fellow employees. > Having some criteria that states they have to have contributed to some > threshold in a breadth of facets in the community would help with this. > > Ask yourself honestly, how would you vote on a Committer/PMC nomination of an > anonymous community member that has only had a handful of small commits? Keep > in mind we have approved fellow employees for a handful of small commits. Is > that fair? > > The point is the process need to be fair and without bias for employment and > relationships. The criteria you use to vote +1 on any individual should be > consistent. If the community honestly thinks we are doing this already then > there isn’t a problem. I don’t think we are. I think we have a problem. > > -Jake > > >> On May 30, 2019, at 4:17 PM, Owen Nichols <onich...@pivotal.io> wrote: >> >> 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 >> <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 >>> <mailto: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> >>> >>> <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/ >
