Setting the commit bar for OODT?

[Justin Erenkrantz <ju...@erenkrantz.com>]

Instead of having this conversation on oodt-private@, I think it might
be useful to have this discussion in public.

What are folks's feeling around where/when we should offer commit
privileges to OODT codebase?

In the projects I've been involved with, there have been two philosophies:
 - Commit access requires sustained contributions over a period of
time (at least six months for httpd; ~2 months for APR)
 - Commit access should be granted like candy [Subversion]

Subversion has an additional dimension (which got Subversion in
trouble during the Incubator; but...well...Greg "resolved" that
problem *chuckle*) which allows any full committer to "sponsor" a
person for partial commit access.  Anyway, here is Subversion's
write-up regarding commit access:
  http://subversion.apache.org/docs/community-guide/roles.html#committers

Subversion's philosophy is centered around "trust" and "Um, it's all
under version control so really what harm could anyone do?"...httpd's
is around "this is a complex codebase; we only want committers who
understand it".  Both are perfectly valid.  The only people who should
be committers are people you are comfortable working with.

There are many right answers to this issue - but I think it'd be good
to make it clear what our expectations are.  Whatever the decision is
would also be good to put a blurb up on our OODT website and
documentation (even in a top-level README).

Thoughts?  It'd be great for *everyone* (committers or not!) on-list
to chime in.  =)  -- justin

P.S. This thought came up as I looked at the patches recently applied
from JIRA and wondering where the commit bar should be.

Re: Setting the commit bar for OODT?

[David M Woollard <wo...@jpl.nasa.gov>]

Chris, 

I think this is a great enumeration of possible paths. I agree in the end that more people feeling positive about their involvement with OODT is an important factor in developing the external community that we need. I think that a good part of that is commit access. I would be in favor of setting the bar relatively low, but not giving it out "like candy." 

As long as we are in a position of reviewing patches quickly and getting back to people, why not have the approach be, "give us a patch or two, figure out how to be a good developer on the project by understanding the site, unit tests, etc., and then we will give you access." IMO, this is a relatively low bar (others feel free to chime in). I'm not interested in playing overlord to anyone, nor do I want to be in a position where we have a butch of committers that i don't feel conformable trusting. To that end, I feel like what Chris suggested is enough to give me warm and fuzzy feelings about the potential committer.

Of course, things change over time, and if, a year from now, we see people who want to be involved have patches sit around for 6+ months (as is the case on some other projects), then we might need to revisit the issue.

-Dave

On Aug 16, 2010, at 10:41 PM, Mattmann, Chris A (388J) wrote:

> Hey Justin,
> 
> Great thoughts, and great to have the discussion in public.
> 
> I¹ve seen a lot of different models for this, mainly based on criteria like:
> 
> A) time a contributor has to wait
> B) complexity of patches submitted by a contributor
> C) resistance to contributor's patches by committership/PMC for whatever
> reason (business, resistance to personalities, etc.)
> D) recognition of support/assistance at the *right time* from contributors
> 
> To me the single most important factor has really been D (which is really
> dependent on where the project is in its life). I've seen projects go from
> totally healthy to stagnant, and see the bar for committership change based
> on that. I remember way back in the Nutch days in 2005, when Hadoop, Tika
> and a slew of other projects were all incubating inside of it, the bar for
> committership was VERY high. I (and other contributors but not committers)
> had something like the httpd/APR experience, but even worse.
> 
> I've seen Nutch go from that in 2005-2007, to stagnating and nearly dying
> off, to some fresh new blood coming in, and to us doing some internal gazing
> at whether or not we should loosen the bar to encourage those that are
> contributing via documentation or emails, or that have contributed even a
> few decent patches to be considered for committership, because let's be
> honest, it's a honor, and it really does motivate a contributor to be
> *rewarded* with a gold Apache badge in the form of an email address and SVN
> access.
> 
> I've also seen projects be very open from the get-go, and encouraging of new
> contributors which I'd classify as my Tika experience. It's really worked
> out, and we usually have folks like Jukka who are great at monitoring who's
> helping out even a little bit and who is on our watchlist and things like
> that.
> 
> For OODT...I really think we're at a point where my personal belief is to
> reward those that show interest, and that are willing to try things like:
> 
> 1. building the website, and updating documentation (Sean Kelly's OODT site
> builder rox, it's the perfect combination of Python, Java, Maven, and well a
> dozen other technologies I don't really understand). LOL. That said, running
> the process here [1] to build the website and test out a new website patch
> is a feat in itself and those that have success in doing this even 1x times,
> and that submit a patch for it should be considered for committership at
> some point soonish.
> 
> 2. fixing bugs - we've had less of these types of patches from outside the
> committership, but that's probably a function of just trying to get the
> OODT@apache code building and the licenses fixed, and all the JPL specific
> stuff removed. It's been a huge effort on that part, and we're just now at a
> point where the code is really useable. So, a lot of the bugs/etc. patches
> that will be coming here in the near future will still likely be folks who
> are using OODT in their existing environments, but who have found/fixed bugs
> that can be turned around and started to be ported to Apache OODT, which is
> what we're asking all existing OODT projects to do.
> 
> 3. running unit tests and helping to get the existing build working and in
> tip-top order so we can make a release. This has mostly been a committer
> activity so far, but we did get a patch way back when from the CHLA folks
> who were trying to help out on this.
> 
> 4. New documentation, graphics, logos. We had some great contributions from
> the CHLA folks on these too.
> 
> Of course, the complexity, quality, and timeliness of patches in 1-4 above
> will vary *significantly*, but at this stage, my feeling would be to gain as
> many helping hands as possible during Incubation (the greater the diversity
> the merrier in terms of organizations and those individuals contributing)
> and to be more inclusive on the committership side than exclusive, but
> that's just me.
> 
> Others, chime in, please!
> 
> Cheers,
> Chris
> 
> [1] http://s.apache.org/iX
> 
> 
> On 8/16/10 10:18 PM, "Justin Erenkrantz" <ju...@erenkrantz.com> wrote:
> 
>> Instead of having this conversation on oodt-private@, I think it might
>> be useful to have this discussion in public.
>> 
>> What are folks's feeling around where/when we should offer commit
>> privileges to OODT codebase?
>> 
>> In the projects I've been involved with, there have been two philosophies:
>> - Commit access requires sustained contributions over a period of
>> time (at least six months for httpd; ~2 months for APR)
>> - Commit access should be granted like candy [Subversion]
>> 
>> Subversion has an additional dimension (which got Subversion in
>> trouble during the Incubator; but...well...Greg "resolved" that
>> problem *chuckle*) which allows any full committer to "sponsor" a
>> person for partial commit access.  Anyway, here is Subversion's
>> write-up regarding commit access:
>>  http://subversion.apache.org/docs/community-guide/roles.html#committers
>> 
>> Subversion's philosophy is centered around "trust" and "Um, it's all
>> under version control so really what harm could anyone do?"...httpd's
>> is around "this is a complex codebase; we only want committers who
>> understand it".  Both are perfectly valid.  The only people who should
>> be committers are people you are comfortable working with.
>> 
>> There are many right answers to this issue - but I think it'd be good
>> to make it clear what our expectations are.  Whatever the decision is
>> would also be good to put a blurb up on our OODT website and
>> documentation (even in a top-level README).
>> 
>> Thoughts?  It'd be great for *everyone* (committers or not!) on-list
>> to chime in.  =)  -- justin
>> 
>> P.S. This thought came up as I looked at the patches recently applied
>> from JIRA and wondering where the commit bar should be.
>> 
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 

Re: Setting the commit bar for OODT?

[Paul Zimdars <pz...@jpl.nasa.gov>]

  Hi Chris,

I am a newcomer on the scene but IMHO I believe you hit on some
excellent points. I have worked with you and the OODT gang on the JPL
side of the house and I completely agree that an open and clear method
of contributing to the community and being recognized for is definitely
a big +1. This allows for "new blood" to be encouraged and rewarded for
showing interest and providing support to new and upcoming projects such
as OODT.

Cheers!
Paul
On 8/16/2010 10:41 PM, Mattmann, Chris A (388J) wrote:
> Hey Justin,
>
> Great thoughts, and great to have the discussion in public.
>
> I¹ve seen a lot of different models for this, mainly based on criteria like:
>
> A) time a contributor has to wait
> B) complexity of patches submitted by a contributor
> C) resistance to contributor's patches by committership/PMC for whatever
> reason (business, resistance to personalities, etc.)
> D) recognition of support/assistance at the *right time* from contributors
>
> To me the single most important factor has really been D (which is really
> dependent on where the project is in its life). I've seen projects go from
> totally healthy to stagnant, and see the bar for committership change based
> on that. I remember way back in the Nutch days in 2005, when Hadoop, Tika
> and a slew of other projects were all incubating inside of it, the bar for
> committership was VERY high. I (and other contributors but not committers)
> had something like the httpd/APR experience, but even worse.
>
> I've seen Nutch go from that in 2005-2007, to stagnating and nearly dying
> off, to some fresh new blood coming in, and to us doing some internal gazing
> at whether or not we should loosen the bar to encourage those that are
> contributing via documentation or emails, or that have contributed even a
> few decent patches to be considered for committership, because let's be
> honest, it's a honor, and it really does motivate a contributor to be
> *rewarded* with a gold Apache badge in the form of an email address and SVN
> access.
>
> I've also seen projects be very open from the get-go, and encouraging of new
> contributors which I'd classify as my Tika experience. It's really worked
> out, and we usually have folks like Jukka who are great at monitoring who's
> helping out even a little bit and who is on our watchlist and things like
> that.
>
> For OODT...I really think we're at a point where my personal belief is to
> reward those that show interest, and that are willing to try things like:
>
> 1. building the website, and updating documentation (Sean Kelly's OODT site
> builder rox, it's the perfect combination of Python, Java, Maven, and well a
> dozen other technologies I don't really understand). LOL. That said, running
> the process here [1] to build the website and test out a new website patch
> is a feat in itself and those that have success in doing this even 1x times,
> and that submit a patch for it should be considered for committership at
> some point soonish.
>
> 2. fixing bugs - we've had less of these types of patches from outside the
> committership, but that's probably a function of just trying to get the
> OODT@apache code building and the licenses fixed, and all the JPL specific
> stuff removed. It's been a huge effort on that part, and we're just now at a
> point where the code is really useable. So, a lot of the bugs/etc. patches
> that will be coming here in the near future will still likely be folks who
> are using OODT in their existing environments, but who have found/fixed bugs
> that can be turned around and started to be ported to Apache OODT, which is
> what we're asking all existing OODT projects to do.
>
> 3. running unit tests and helping to get the existing build working and in
> tip-top order so we can make a release. This has mostly been a committer
> activity so far, but we did get a patch way back when from the CHLA folks
> who were trying to help out on this.
>
> 4. New documentation, graphics, logos. We had some great contributions from
> the CHLA folks on these too.
>
> Of course, the complexity, quality, and timeliness of patches in 1-4 above
> will vary *significantly*, but at this stage, my feeling would be to gain as
> many helping hands as possible during Incubation (the greater the diversity
> the merrier in terms of organizations and those individuals contributing)
> and to be more inclusive on the committership side than exclusive, but
> that's just me.
>
> Others, chime in, please!
>
> Cheers,
> Chris
>
> [1] http://s.apache.org/iX
>
>
> On 8/16/10 10:18 PM, "Justin Erenkrantz"<ju...@erenkrantz.com>  wrote:
>
>> Instead of having this conversation on oodt-private@, I think it might
>> be useful to have this discussion in public.
>>
>> What are folks's feeling around where/when we should offer commit
>> privileges to OODT codebase?
>>
>> In the projects I've been involved with, there have been two philosophies:
>>   - Commit access requires sustained contributions over a period of
>> time (at least six months for httpd; ~2 months for APR)
>>   - Commit access should be granted like candy [Subversion]
>>
>> Subversion has an additional dimension (which got Subversion in
>> trouble during the Incubator; but...well...Greg "resolved" that
>> problem *chuckle*) which allows any full committer to "sponsor" a
>> person for partial commit access.  Anyway, here is Subversion's
>> write-up regarding commit access:
>>    http://subversion.apache.org/docs/community-guide/roles.html#committers
>>
>> Subversion's philosophy is centered around "trust" and "Um, it's all
>> under version control so really what harm could anyone do?"...httpd's
>> is around "this is a complex codebase; we only want committers who
>> understand it".  Both are perfectly valid.  The only people who should
>> be committers are people you are comfortable working with.
>>
>> There are many right answers to this issue - but I think it'd be good
>> to make it clear what our expectations are.  Whatever the decision is
>> would also be good to put a blurb up on our OODT website and
>> documentation (even in a top-level README).
>>
>> Thoughts?  It'd be great for *everyone* (committers or not!) on-list
>> to chime in.  =)  -- justin
>>
>> P.S. This thought came up as I looked at the patches recently applied
>> from JIRA and wondering where the commit bar should be.
>>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>

Re: Setting the commit bar for OODT?

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

Hey Justin,

Great thoughts, and great to have the discussion in public.

I¹ve seen a lot of different models for this, mainly based on criteria like:

A) time a contributor has to wait
B) complexity of patches submitted by a contributor
C) resistance to contributor's patches by committership/PMC for whatever
reason (business, resistance to personalities, etc.)
D) recognition of support/assistance at the *right time* from contributors

To me the single most important factor has really been D (which is really
dependent on where the project is in its life). I've seen projects go from
totally healthy to stagnant, and see the bar for committership change based
on that. I remember way back in the Nutch days in 2005, when Hadoop, Tika
and a slew of other projects were all incubating inside of it, the bar for
committership was VERY high. I (and other contributors but not committers)
had something like the httpd/APR experience, but even worse.

I've seen Nutch go from that in 2005-2007, to stagnating and nearly dying
off, to some fresh new blood coming in, and to us doing some internal gazing
at whether or not we should loosen the bar to encourage those that are
contributing via documentation or emails, or that have contributed even a
few decent patches to be considered for committership, because let's be
honest, it's a honor, and it really does motivate a contributor to be
*rewarded* with a gold Apache badge in the form of an email address and SVN
access.

I've also seen projects be very open from the get-go, and encouraging of new
contributors which I'd classify as my Tika experience. It's really worked
out, and we usually have folks like Jukka who are great at monitoring who's
helping out even a little bit and who is on our watchlist and things like
that.

For OODT...I really think we're at a point where my personal belief is to
reward those that show interest, and that are willing to try things like:

1. building the website, and updating documentation (Sean Kelly's OODT site
builder rox, it's the perfect combination of Python, Java, Maven, and well a
dozen other technologies I don't really understand). LOL. That said, running
the process here [1] to build the website and test out a new website patch
is a feat in itself and those that have success in doing this even 1x times,
and that submit a patch for it should be considered for committership at
some point soonish.

2. fixing bugs - we've had less of these types of patches from outside the
committership, but that's probably a function of just trying to get the
OODT@apache code building and the licenses fixed, and all the JPL specific
stuff removed. It's been a huge effort on that part, and we're just now at a
point where the code is really useable. So, a lot of the bugs/etc. patches
that will be coming here in the near future will still likely be folks who
are using OODT in their existing environments, but who have found/fixed bugs
that can be turned around and started to be ported to Apache OODT, which is
what we're asking all existing OODT projects to do.

3. running unit tests and helping to get the existing build working and in
tip-top order so we can make a release. This has mostly been a committer
activity so far, but we did get a patch way back when from the CHLA folks
who were trying to help out on this.

4. New documentation, graphics, logos. We had some great contributions from
the CHLA folks on these too.

Of course, the complexity, quality, and timeliness of patches in 1-4 above
will vary *significantly*, but at this stage, my feeling would be to gain as
many helping hands as possible during Incubation (the greater the diversity
the merrier in terms of organizations and those individuals contributing)
and to be more inclusive on the committership side than exclusive, but
that's just me.

Others, chime in, please!

Cheers,
Chris

[1] http://s.apache.org/iX


On 8/16/10 10:18 PM, "Justin Erenkrantz" <ju...@erenkrantz.com> wrote:

> Instead of having this conversation on oodt-private@, I think it might
> be useful to have this discussion in public.
> 
> What are folks's feeling around where/when we should offer commit
> privileges to OODT codebase?
> 
> In the projects I've been involved with, there have been two philosophies:
>  - Commit access requires sustained contributions over a period of
> time (at least six months for httpd; ~2 months for APR)
>  - Commit access should be granted like candy [Subversion]
> 
> Subversion has an additional dimension (which got Subversion in
> trouble during the Incubator; but...well...Greg "resolved" that
> problem *chuckle*) which allows any full committer to "sponsor" a
> person for partial commit access.  Anyway, here is Subversion's
> write-up regarding commit access:
>   http://subversion.apache.org/docs/community-guide/roles.html#committers
> 
> Subversion's philosophy is centered around "trust" and "Um, it's all
> under version control so really what harm could anyone do?"...httpd's
> is around "this is a complex codebase; we only want committers who
> understand it".  Both are perfectly valid.  The only people who should
> be committers are people you are comfortable working with.
> 
> There are many right answers to this issue - but I think it'd be good
> to make it clear what our expectations are.  Whatever the decision is
> would also be good to put a blurb up on our OODT website and
> documentation (even in a top-level README).
> 
> Thoughts?  It'd be great for *everyone* (committers or not!) on-list
> to chime in.  =)  -- justin
> 
> P.S. This thought came up as I looked at the patches recently applied
> from JIRA and wondering where the commit bar should be.
> 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++