geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Nichols <>
Subject Re: [DISCUSS] Criteria for PMC, committers
Date Fri, 31 May 2019 09:41:12 GMT
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. 


> On May 30, 2019, at 10:23 PM, Jacob Barrett <> 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 <> 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 <>
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 < <>>
>>> 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.
>>>> On May 29, 2019, at 10:13 AM, Anthony Baker <> 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]
>>>> [2]
>>>> [3]
>>>> [4]
>>>> [5]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message