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] Remove exception.getMessage() error handling

[Owen Nichols]

It sounds like the consensus is: don’t change [the current questionable uses of 
getMessage] unless willing go a step further and provide a detailed, 
informative message, which may include the exception’s toString.

Thanks.
-Owen

> On May 28, 2019, at 3:32 PM, Nabarun Nag  wrote:
> 
> Looking at the ticket, it looks like it is an improvement request for some
> additional information for the end user, can we just do what Kirk and Bruce
> suggested. Add some logs to explain what happened. In my opinion, an end
> user will be more happy to get some detail information rather than an
> exception class name.
> 
> Regards
> Nabarun Nag
> 
> On Tue, May 28, 2019 at 3:08 PM Owen Nichols  wrote:
> 
>> This example came from https://issues.apache.org/jira/browse/GEODE-6796
>> in which the submitter assumed that Geode was deliberately emitting a
>> poorly-worded and confusing error message.
>> 
>> @abaker It sounds like your recommendation for this particular ticket
>> would be to resolve as ’Not A Bug’, is that correct?
>> 
>>> On May 28, 2019, at 10:03 AM, Anthony Baker  wrote:
>>> 
>>> In the example you provided, I don’t agree that adding the exception
>> class name creates a better user experience.
>>> 
>>> Anthony
>>> 
>>> 
 On May 25, 2019, at 6:39 PM, Owen Nichols  wrote:
 
 Here’s an example of a message that was logged before Jack’s change:
 
 l192.168.99.1: nodename nor servname provided, or not known
 
 Here’s what it will look like now with .toString() instead of
>> .getMessage():
 
 java.net.UnknownHostException: l192.168.99.1: nodename nor servname
>> provided, or not known
 
 
 I cannot think of a single good reason to ever print an exception’s
>> message stripped of all context.  As Jack noted, many exceptions don’t even
>> have a message; the key information is the class of the exception itself.
>> Even if you aren’t catching Exception but rather some very specific
>> subclass, code should never make assumptions about the text of an exception
>> (see PR#3616  for a recent
>> example).
 
 
 @jinmei There is no built-in method in java to capture the entire
>> stacktrace as a string.  Exception::toString() just concatenates the
>> exception class name and message (i.e. the first line only of a full
>> stacktrace)
 
 
> On May 24, 2019, at 3:37 PM, Dan Smith  wrote:
> 
> I think the right thing to do in those 100+ cases may be different in
>> each
> case, a blanket search and replace might not be the best idea.
> 
> -Dan
> 
> 
> 
> On Fri, May 24, 2019 at 3:05 PM Jinmei Liao  wrote:
> 
>> does exception.toString() print out the entire stack trace? If so, I
>> don't
>> think we should use that to replace exception.getMessage().
>> 
>> On Fri, May 24, 2019 at 1:18 PM Jack Weissburg >> 
>> wrote:
>> 
>>> Hi All,
>>> 
>>> Owen and I investigated a strange error message caused because Geode
>>> previously handled an error exception with exception.getMessage()
>> instead
>>> of
>>> exception.toString().
>>> 
>>> The issue is that the exception message from exception.getMessage()
>> could
>>> be unhelpful or empty. Instead, we should return the whole exception
>> via
>>> exception.toString().
>>> 
>>> exception.getMessage()is used widely throughout the Geode code base
>> (100+
>>> times) and could be prone to cause more issues similar to
>>> https://issues.apache.org/jira/browse/GEODE-6796
>>> I would like to change the remaining instances of
>> exception.getMessage()to
>>> avoid future issues of this variety.
>>> 
>>> Thoughts? Comments?
>>> 
>>> Best,
>>> Jack Weissburg
>>> 
>> 
>> 
>> --
>> Cheers
>> 
>> Jinmei
>> 
 
>>> 
>> 
>> 

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/