Re: [DISCUSS] Criteria for PMC, committers

[Dan Smith]

One concern I have about not bundling committer and PMC membership is that
there is not much incentive to nominate someone to become a PMC member.
When someone is an active contributor but not a committer it's visible in
the fact that they have to ask others to merge their PRs, which also
provides incentive to nominate them. But once they are a committer it's not
really obvious that someone is not also a PMC member, so there is no
reminder to nominate them for the next step.

For that reason I think we should continue bundling the two.

I'm also concerned with the "mateship bias" that Udo described. I do think
evidence of good judgement and a sense of responsibility is much more
important than the code that a nominee writes, and that's much easier to
judge if you have more contact with them. But maybe we can look for that
evidence specifically in the mailing list and PR comments?

-Dan

On Tue, Jun 4, 2019 at 2:59 PM Mark Bretl  wrote:

> I think in any point of view we are looking at Committer or PMC membership,
> it does come down to merit. Does the person have the merit, which can also
> be trust, to be a Committer and/or PMC member?
>
> The difference between Committer and PMC member is not simply being
> 'gatekeepers' of the codebase, PMC members provide oversight to the entire
> project [1], which I cannot put the same responsibility on a Committer. I
> don't think there has to a promotion path in terms of Committer -> PMC,
> however, I do believe there is a distinction between the two, especially
> since it is the Apache Board which ultimately makes the decision for PMC
> membership. A candidate be nominated for both at one time, but then it
> would be an all or nothing vote.
>
> --Mark
>
> [1]: https://www.apache.org/foundation/governance/pmcs.html
>
> On Fri, May 31, 2019 at 3:17 PM Jacob Barrett  wrote:
>
> > I think it's a lot of what is under the contributing section, but I think
> > it needs to be cleaned up. A lot of the what should be done is lost under
> > the screen shots of things. I nice clear bullet point, with maybe links
> to
> > the wiki for details, would be nice. If we collected all of this in the
> > CONTRIBUTING.md its right there in your source and baked into GitHub,
> which
> > is the primary place developers go, not the wiki. Then our PR template
> > could just say something like “[ ] complies with contributing
> guidelines”.
> > Eh??
> >
> > -Jake
> >
> >
> > > On May 31, 2019, at 3:12 PM, Anthony Baker  wrote:
> > >
> > > Are you thinking in terms of something like this?
> > > https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct <
> > https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct>
> > >
> > > Or something more specific to coding tasks?
> > >
> > >
> > > Thanks,
> > > Anthony
> > >
> > >
> > >> On May 31, 2019, at 2:41 AM, Owen Nichols 
> wrote:
> > >>
> > >> 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.
> > >
> >
> >
>

Re: [DISCUSS] Criteria for PMC, committers

[Mark Bretl]

I think in any point of view we are looking at Committer or PMC membership,
it does come down to merit. Does the person have the merit, which can also
be trust, to be a Committer and/or PMC member?

The difference between Committer and PMC member is not simply being
'gatekeepers' of the codebase, PMC members provide oversight to the entire
project [1], which I cannot put the same responsibility on a Committer. I
don't think there has to a promotion path in terms of Committer -> PMC,
however, I do believe there is a distinction between the two, especially
since it is the Apache Board which ultimately makes the decision for PMC
membership. A candidate be nominated for both at one time, but then it
would be an all or nothing vote.

--Mark

[1]: https://www.apache.org/foundation/governance/pmcs.html

On Fri, May 31, 2019 at 3:17 PM Jacob Barrett  wrote:

> I think it's a lot of what is under the contributing section, but I think
> it needs to be cleaned up. A lot of the what should be done is lost under
> the screen shots of things. I nice clear bullet point, with maybe links to
> the wiki for details, would be nice. If we collected all of this in the
> CONTRIBUTING.md its right there in your source and baked into GitHub, which
> is the primary place developers go, not the wiki. Then our PR template
> could just say something like “[ ] complies with contributing guidelines”.
> Eh??
>
> -Jake
>
>
> > On May 31, 2019, at 3:12 PM, Anthony Baker  wrote:
> >
> > Are you thinking in terms of something like this?
> > https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct <
> https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct>
> >
> > Or something more specific to coding tasks?
> >
> >
> > Thanks,
> > Anthony
> >
> >
> >> On May 31, 2019, at 2:41 AM, Owen Nichols  wrote:
> >>
> >> 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.
> >
>
>

Re: [DISCUSS] Criteria for PMC, committers

[Jacob Barrett]

I think it's a lot of what is under the contributing section, but I think it 
needs to be cleaned up. A lot of the what should be done is lost under the 
screen shots of things. I nice clear bullet point, with maybe links to the wiki 
for details, would be nice. If we collected all of this in the CONTRIBUTING.md 
its right there in your source and baked into GitHub, which is the primary 
place developers go, not the wiki. Then our PR template could just say 
something like “[ ] complies with contributing guidelines”. Eh??

-Jake


> On May 31, 2019, at 3:12 PM, Anthony Baker  wrote:
> 
> Are you thinking in terms of something like this?
> https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct 
> 
> 
> Or something more specific to coding tasks?
> 
> 
> Thanks,
> Anthony
> 
> 
>> On May 31, 2019, at 2:41 AM, Owen Nichols  wrote:
>> 
>> 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.
> 

Re: [DISCUSS] Criteria for PMC, committers

[Anthony Baker]

Are you thinking in terms of something like this?
https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct 


Or something more specific to coding tasks?


Thanks,
Anthony


> On May 31, 2019, at 2:41 AM, Owen Nichols  wrote:
> 
> 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.

Re: [DISCUSS] Criteria for PMC, committers

[Udo Kohlmeyer]

@Owen Some interesting thoughts and proposals. None of which I think we 
could easily implement, but some that I would LOVE to have.


I also apologize for restating many things that Helena has already said, 
but it is taking my a long time to craft this email...


Jake has raised a concern that I share. In too many cases contributors 
are made committers on the basis of "mateship" and less on tangible 
contributions. I remember cases where proposed committers were rejected 
for not having been active enough on mailing lists or even PR. Yet in 
other cases no contributions on mailing lists are over shadowed by the 
sheer volume of PR's submitted, resulting in the granting of committer 
(and pmc) rights. In most successful (nomination cases) the nominee sat 
in the same office,same team, had breakfast/lunch/coffee and socialized 
with many other Geode committers/pmc members. Which automatically evokes 
a "mateship" bias. "The person is a nice person and I enjoy working with 
them" very often overshadows the lack of dev/user list contributions or 
PR's.


Having guidelines based code quality and technical knowledge is only 
part the criteria. Activity in the community (mailing lists) is the 
other part that should be considered. All of these, are factors in 
determining a committer.


As a PMC member I also ask myself the questions:

 * "Do I as a PMC member trust that all future commits from a nominee
   to be of the same high standard going forward?"
 * "Will this nominee continue to be active on mailing lists and the
   community at large."
 * "Am I convinced that the PR's that I am seeing is really that of the
   nominee and not that of a team effort of pair programming with
   another committer/pmc member".
   
(https://github.com/apache/geode/pull/3650,https://github.com/apache/geode/pull/3573).


How am I to judge the quality of work of  the nominee when multiple 
developers were part of it? I have witnessed this in many cases, where 
developers submit PR's under their name, but the main body of work was 
predominantly done by their more experienced pair. Synthetic bolstering 
of PR number to use as "fact" when it comes to committer nomination. In 
these cases I look to the mailing lists to gain insight into that 
nominees understanding of project and problem area, rather than can they 
write compliant code.


Being a PMC member, imo, is another role that should be evaluated on, 
after having become a committer. Activity in mailing list, reviewing of 
PR's (yes a committer's responsibility, AND imo an evaluation criteria), 
shows commitment to the project. Commitment to the project results in 
rights to become a PMC member. Once again there are no metrics (or exact 
numbers) that we can attribute to this, BUT subjectively everyone can 
evaluate the contributions and gauge if they feel the nominee is strong 
enough. As a side note, anonymization would be awesome here.. take away 
the face and familiarity and only evaluate on contributions would be 
SOOO much simpler. But alas too much work and most likely complete and 
utter overkill.


@Owen, you are correct, a single -1 is a strong signal that something is 
not as clear or apparent to a single PMC member as it is to many others. 
This is why a reason is required. This also allows space for other PMC 
members to present their views on the nominee, which might not be as 
apparent to others. In some cases I feel maybe reasons should accompany 
a +1. I mean, why would a -1 need justification and a +1 does not. THAT 
+1 justification might just sway a -1 to change their mind to a "0" or 
even a "+1".


I also want to highlight another elephant in the room. Out of 100 
(registered) committers and 50 (registered) pmc members, only 6 have 
commented on this thread. Pause for thought.


--Udo

On 5/31/19 02:41, Owen Nichols 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 

Re: [DISCUSS] Criteria for PMC, committers

[Helena Bales]

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  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  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 

Re: [DISCUSS] Criteria for PMC, committers

[Owen Nichols]

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  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 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 >> > 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 

Re: [DISCUSS] Criteria for PMC, committers

[Jacob Barrett]

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 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 > > 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
>>  
>> 
>>  
>> >  
>> >
>> 
>> 
>>> On May 29, 2019, at 10:13 AM, Anthony Baker  wrote:
>>> 
>>> I think it’s time to 

Re: [DISCUSS] Criteria for PMC, committers

[Owen Nichols]

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 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  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
>  
> 
> 
> 
>> 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 

Re: [DISCUSS] Criteria for PMC, committers

[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.
https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Community+Roles+and+Processes
 



> 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] 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/
> 
> 

Re: [DISCUSS] Criteria for PMC, committers

[Owen Nichols]

I don’t see a compelling reason for Geode to make a distinction between 
committer and PMC member.

If you have the power to merge PRs, you are a steward of the codebase; 
we need to be able to trust that you have Geode’s best interests at heart and 
will adhere to our practices. 

PMC membership confers the additional benefit of voting rights on releases and 
new committers.  To me, the requirements are no different; 
we need to be able to trust that you have Geode’s best interests at heart and 
will adhere to our practices. 

If the idea is to restrict the PMC to a smaller set of “gatekeepers" to ensure 
we don’t make a release containing a bad commit, that implies that we don’t 
actually trust committers (or that being both a committer and a PMC member 
could somehow be a conflict of interest).

Let’s keep things simple and extend trust and voting rights at the same time, 
or not at all.

-Owen

> On May 29, 2019, at 1:19 PM, Ryan McMahon  wrote:
> 
> My two cents...
> 
> 1) What is our criteria for becoming a committer and PMC member?
> I don't have anything particularly enlightening to say here, and I think I
> am just reinforcing what we already do, but here goes...
> 
> I think this piece from the ASF notes is key for measuring candidacy for
> committer/PMC status, but still quite subjective:
> 
> contributions from non-committers - both specific code patches, bugs
>> reported or commented on, or just helpful interaction on their project
>> lists - [are used] to evaluate contributors as potential committers
> 
> 
> It is hard to quantify the value of contributions from non-committers
> (number of code patches?  quality of code patches?  number of feature
> ideas/bugs reported?  number of times replied on a dev list thread?).  I
> think we have to consider each candidate on a case-by-case basis with these
> things in mind.  I'm not sure we can fairly create hard and fast rules like
> a candidate must have filed X tickets and written Y comments.  As is
> pointed out in your third bullet point, we have to decide whether we've
> gained confidence and trust the contributor to make the right decision when
> considering things like merging code and PR reviewing.  Again, this is all
> very subjective so I feel it has to be evaluated on a case-by-case basis,
> which is basically what we have always done.  I would love to hear of more
> objective/quantitative ways of measuring this sort of thing though, if
> people have ideas.
> 
> 2) Do we have separate criteria for committers and PMC members (and thus
> should elect them separately)?
> I think we should continue to bundle the two.  I haven't heard a compelling
> reason for separating the two, and bundling them simplifies the process
> somewhat.
> 
> Ryan
> 
> On Wed, May 29, 2019 at 10:17 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] 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
>> 

Re: [DISCUSS] Criteria for PMC, committers

[Ryan McMahon]

My two cents...

1) What is our criteria for becoming a committer and PMC member?
I don't have anything particularly enlightening to say here, and I think I
am just reinforcing what we already do, but here goes...

I think this piece from the ASF notes is key for measuring candidacy for
committer/PMC status, but still quite subjective:

contributions from non-committers - both specific code patches, bugs
> reported or commented on, or just helpful interaction on their project
> lists - [are used] to evaluate contributors as potential committers


It is hard to quantify the value of contributions from non-committers
(number of code patches?  quality of code patches?  number of feature
ideas/bugs reported?  number of times replied on a dev list thread?).  I
think we have to consider each candidate on a case-by-case basis with these
things in mind.  I'm not sure we can fairly create hard and fast rules like
a candidate must have filed X tickets and written Y comments.  As is
pointed out in your third bullet point, we have to decide whether we've
gained confidence and trust the contributor to make the right decision when
considering things like merging code and PR reviewing.  Again, this is all
very subjective so I feel it has to be evaluated on a case-by-case basis,
which is basically what we have always done.  I would love to hear of more
objective/quantitative ways of measuring this sort of thing though, if
people have ideas.

2) Do we have separate criteria for committers and PMC members (and thus
should elect them separately)?
I think we should continue to bundle the two.  I haven't heard a compelling
reason for separating the two, and bundling them simplifies the process
somewhat.

Ryan

On Wed, May 29, 2019 at 10:17 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] 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/
>
>
>

[DISCUSS] Criteria for PMC, committers

[Anthony Baker]

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/