I agree with Jake that the lack of guidelines is an issue that introduces our own biases. I don't think this means that we need to change our process, but rather that we need to formalize it. If a -1 vote requires a justification, then we need to have expectations defined. It's a lot harder to argue that someone doesn't meet the requirements when not everyone is on the same page regarding what the requirements are. We should have a publicly available document that outlines these guidelines, so that everyone can read them, including the contributor about whom we are voting. This process currently lacks transparency and consistency by evaluating different contributors by different metrics.
That said, I don't think we should have some arbitrary number of commits, emails, etc. as the requirement. Instead, I would favor guidelines that outline the criteria that we consider when evaluating a new committer, such as quantity and quality of commits, activity in the review process, participation on the dev list, etc. I know this list already exists, but I think that we could flush it out in a way that provides guidelines for a more objective evaluation while still leaving room for the consideration of trust. In my mind, this looks somewhat like an English class rubric, with "poor" -> "excellent" on the horizontal axis, and expectations like "contributes in the review process with attention to detail and kindness" (as an example) on the vertical axis. Additionally, as committers/PMC members, we all need to be aware of our implicit biases towards people that we know personally and we need to be prepared to evaluate people on the quality of their work rather than on our relationship with them. If we each make an effort to be aware of our biases, and have a clear set of attributes to evaluate, I think we could vastly improve this process and reduce the impact of our biases. On Fri, May 31, 2019 at 2:41 AM Owen Nichols <onich...@pivotal.io> wrote: > 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/ > > > >
