You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Anthony Baker <ab...@pivotal.io> on 2019/05/29 17:13:22 UTC
[DISCUSS] Criteria for PMC, committers
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
Posted by Owen Nichols <on...@pivotal.io>.
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 <mc...@apache.org> 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 <ab...@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/
>>
>>
>>
Re: [DISCUSS] Criteria for PMC, committers
Posted by Ryan McMahon <mc...@apache.org>.
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 <ab...@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/
>
>
>
Re: [DISCUSS] Criteria for PMC, committers
Posted by Udo Kohlmeyer <ud...@apache.org>.
@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 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 <jb...@pivotal.io> 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 <on...@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 <jbarrett@pivotal.io <ma...@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 <ab...@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/
>
Re: [DISCUSS] Criteria for PMC, committers
Posted by Dan Smith <ds...@pivotal.io>.
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 <mb...@apache.org> 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 <jb...@pivotal.io> 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 <ab...@pivotal.io> 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 <on...@pivotal.io>
> 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
Posted by Mark Bretl <mb...@apache.org>.
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 <jb...@pivotal.io> 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 <ab...@pivotal.io> 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 <on...@pivotal.io> 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
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <ab...@pivotal.io> 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 <on...@pivotal.io> 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
Posted by Anthony Baker <ab...@pivotal.io>.
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 <on...@pivotal.io> 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
Posted by Helena Bales <hb...@pivotal.io>.
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 <on...@pivotal.io> 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 <jb...@pivotal.io> 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 <on...@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 <jbarrett@pivotal.io
> <ma...@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 <ab...@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/
> >
>
>
Re: [DISCUSS] Criteria for PMC, committers
Posted by Owen Nichols <on...@pivotal.io>.
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 <jb...@pivotal.io> 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 <on...@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 <jbarrett@pivotal.io <ma...@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 <ab...@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/
>
Re: [DISCUSS] Criteria for PMC, committers
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <on...@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 <jbarrett@pivotal.io <ma...@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 <ab...@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/
Re: [DISCUSS] Criteria for PMC, committers
Posted by Owen Nichols <on...@pivotal.io>.
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 <jb...@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>
>
>
>> On May 29, 2019, at 10:13 AM, Anthony Baker <ab...@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/
>>
>>
>
Re: [DISCUSS] Criteria for PMC, committers
Posted by Jacob Barrett <jb...@pivotal.io>.
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>
> On May 29, 2019, at 10:13 AM, Anthony Baker <ab...@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/
>
>