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 Thu, 30 May 2019 23:17:05 GMT
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

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.


> On May 29, 2019, at 12:04 PM, Jacob Barrett <> wrote:
> A few observations I have found by looking through the Apache wiki for all the projects
> 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
>> 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
>>> 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