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/
