You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jeff Genender <jg...@savoirtech.com> on 2005/06/22 17:15:27 UTC
Re: Google Summer of Code
Aaron,
Thanks for stepping up and accepting this.
My only .02 on this is you have to be careful about this accellerated
role, and here is why...
In open source, there is no age limit. In fact I believe one of the
main/lead Firefox committers was in his early teens...so committership
should not be offered just because someone becomes an intern. Due to
the fact we have no barrier to entry, including age, nothing prevents a
person from becoming a committer on thier own merits. Anyone can
contribute and play in the sandbox.
My point really is that we have a community that everyone deserves to
enter the geronimo team by hard work, and to accellerate someone due to
internship kind of breaks the rules and may cause some alienation in the
community...especially those who have spent time helping out and have
not been offered committership.
I think the point of being a mentor is to help walk a person through the
process and how things are done...show the open source way and hopefully
have some cool code to show for it at the end of the day. But that
should be done without causing community heartburn.
Here is an idea...
What about an Apache "Summer of Code" ACL for SVN? This allows the
intern to not be an actual committer, but allows them to get the SVN
feel on an opensource project. It would offer a good balance for being
a mentor without causing bad feelings for those who have contributed and
have not been offered committership. What do you think?
Jeff
Aaron Mulder wrote:
> All,
>
> I volunteered to be a mentor for the Google Summer of Code, and
> there were a number of applications for Geronimo. I'm hopeful that at
> least one of them will be accepted.
>
> If that happens, we need to decide how to treat the student for
> the duration of the project (in terms of committership). This is kind of
> a special case in that the program is only a little over 2 months long,
> which means normally we probably wouldn't have made the person a committer
> in that time frame. But given that one of the goals is to teach the
> person how to contribute to open source, it seems to me like we wouldn't
> be doing them justice if we didn't give them commit for at least part of
> the project.
>
> I'd propose that if this goes through, we put the student on an
> "accelerated plan" where we have them contribute their initial work via
> patches, review and provide feedback, and then if all goes well offer them
> commit within the first 2-4 weeks. We will then need to evaluate their
> situation at the end of the program (both their contributions and their
> availability to work with us in the future) and decide whether to end
> their commit status or not (without any prejudice if we do decide to end
> it for whatever reason).
>
> So I'd love to get everyone's feedback on whether this seems OK.
> I specifically want this to be a "special case" -- I don't want to apply
> this to anyone else. I understand that there are a lot of people in the
> community who work hard and contribute and have not been offered commit,
> and I don't want to offend anyone or make anyone feel underappreciated,
> but I do personally feel like mentoring a student to be a future open
> source developer under the terms of this program requires more than simply
> asking them to submit patches.
>
> Let me know!
>
> Thanks,
> Aaron
Re: Google Summer of Code
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 22, 2005, at 4:37 PM, Aaron Mulder wrote:
> Jeff,
> I'm open to the approach you recommend. But I still believe that
> to really teach someone about open source, they need to hold commit on
> something, and be able to break the build and get yelled at, and so
> on.
> If we want to make it clear this is a non-traditional path, we could
> decide to automatically remove commit privileges at the end of the
> project. I'd prefer that we give them the experience and then take it
> away, rather than convince them that the sole function of an open
> source
> developer is to maintain their own source tree and submit patches. I
> guess I'm trying to cram a 1-year experience into a 2-month microcosm.
> But I also agree that we shouldn't frame this as the standard
> practice for
> interns.
>
> Anyone else out there have an opinion?
Isn't the entire process you are describing what we'd want to do with
any new community member who wishes to contribute via committing code?
I'm all for the idea of mentoring, and like the Summer of Code idea
if it helps students to engage with us.
I also like the idea of getting willing contributors going in this
way, no matter who they are, as long as the dedication and alignment
is there - maybe that's what you are identifying with a student
signing up for this, that they are accelerating their demonstration
of commitment to working with the project and community.
How can we quantify and recognize that commitment more generally?
geir
>
> Thanks,
> Aaron
>
> On Wed, 22 Jun 2005, Jeff Genender wrote:
>
>> Aaron,
>>
>> Thanks for stepping up and accepting this.
>>
>> My only .02 on this is you have to be careful about this accellerated
>> role, and here is why...
>>
>> In open source, there is no age limit. In fact I believe one of the
>> main/lead Firefox committers was in his early teens...so
>> committership
>> should not be offered just because someone becomes an intern. Due to
>> the fact we have no barrier to entry, including age, nothing
>> prevents a
>> person from becoming a committer on thier own merits. Anyone can
>> contribute and play in the sandbox.
>>
>> My point really is that we have a community that everyone deserves to
>> enter the geronimo team by hard work, and to accellerate someone
>> due to
>> internship kind of breaks the rules and may cause some alienation
>> in the
>> community...especially those who have spent time helping out and have
>> not been offered committership.
>>
>> I think the point of being a mentor is to help walk a person
>> through the
>> process and how things are done...show the open source way and
>> hopefully
>> have some cool code to show for it at the end of the day. But that
>> should be done without causing community heartburn.
>>
>> Here is an idea...
>>
>> What about an Apache "Summer of Code" ACL for SVN? This allows the
>> intern to not be an actual committer, but allows them to get the SVN
>> feel on an opensource project. It would offer a good balance for
>> being
>> a mentor without causing bad feelings for those who have
>> contributed and
>> have not been offered committership. What do you think?
>>
>> Jeff
>>
>> Aaron Mulder wrote:
>>
>>> All,
>>>
>>> I volunteered to be a mentor for the Google Summer of Code, and
>>> there were a number of applications for Geronimo. I'm hopeful
>>> that at
>>> least one of them will be accepted.
>>>
>>> If that happens, we need to decide how to treat the student for
>>> the duration of the project (in terms of committership). This is
>>> kind of
>>> a special case in that the program is only a little over 2 months
>>> long,
>>> which means normally we probably wouldn't have made the person a
>>> committer
>>> in that time frame. But given that one of the goals is to teach the
>>> person how to contribute to open source, it seems to me like we
>>> wouldn't
>>> be doing them justice if we didn't give them commit for at least
>>> part of
>>> the project.
>>>
>>> I'd propose that if this goes through, we put the student on an
>>> "accelerated plan" where we have them contribute their initial
>>> work via
>>> patches, review and provide feedback, and then if all goes well
>>> offer them
>>> commit within the first 2-4 weeks. We will then need to evaluate
>>> their
>>> situation at the end of the program (both their contributions and
>>> their
>>> availability to work with us in the future) and decide whether to
>>> end
>>> their commit status or not (without any prejudice if we do decide
>>> to end
>>> it for whatever reason).
>>>
>>> So I'd love to get everyone's feedback on whether this seems OK.
>>> I specifically want this to be a "special case" -- I don't want
>>> to apply
>>> this to anyone else. I understand that there are a lot of people
>>> in the
>>> community who work hard and contribute and have not been offered
>>> commit,
>>> and I don't want to offend anyone or make anyone feel
>>> underappreciated,
>>> but I do personally feel like mentoring a student to be a future
>>> open
>>> source developer under the terms of this program requires more
>>> than simply
>>> asking them to submit patches.
>>>
>>> Let me know!
>>>
>>> Thanks,
>>> Aaron
>>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Google Summer of Code
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Aaron Mulder wrote, On 6/23/2005 7:44 PM:
>On Wed, 22 Jun 2005, Alan D. Cabrera wrote:
>
>
>>Could we put him in the sandbox?
>>
>>
>
> That seems like a sensible compromise. I assume we'll want to
>investigate assigning separate commit privs to the sandbox compared to
>Geronimo proper? I've been assured that we could also do the same for a
>branch instead of a subdirectory, which I'd be fine with too.
>
>
It's not really a branch. The sandbox seems more appropriate.
Regards,
Alan
Re: Google Summer of Code
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Wed, 22 Jun 2005, Alan D. Cabrera wrote:
> Could we put him in the sandbox?
That seems like a sensible compromise. I assume we'll want to
investigate assigning separate commit privs to the sandbox compared to
Geronimo proper? I've been assured that we could also do the same for a
branch instead of a subdirectory, which I'd be fine with too.
Aaron
Re: Google Summer of Code
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Could we put him in the sandbox?
Regards,
Alan
Aaron Mulder wrote, On 6/22/2005 1:37 PM:
>Jeff,
> I'm open to the approach you recommend. But I still believe that
>to really teach someone about open source, they need to hold commit on
>something, and be able to break the build and get yelled at, and so on.
>If we want to make it clear this is a non-traditional path, we could
>decide to automatically remove commit privileges at the end of the
>project. I'd prefer that we give them the experience and then take it
>away, rather than convince them that the sole function of an open source
>developer is to maintain their own source tree and submit patches. I
>guess I'm trying to cram a 1-year experience into a 2-month microcosm.
>But I also agree that we shouldn't frame this as the standard practice for
>interns.
>
> Anyone else out there have an opinion?
>
>Thanks,
> Aaron
>
>On Wed, 22 Jun 2005, Jeff Genender wrote:
>
>
>>Aaron,
>>
>>Thanks for stepping up and accepting this.
>>
>>My only .02 on this is you have to be careful about this accellerated
>>role, and here is why...
>>
>>In open source, there is no age limit. In fact I believe one of the
>>main/lead Firefox committers was in his early teens...so committership
>>should not be offered just because someone becomes an intern. Due to
>>the fact we have no barrier to entry, including age, nothing prevents a
>>person from becoming a committer on thier own merits. Anyone can
>>contribute and play in the sandbox.
>>
>>My point really is that we have a community that everyone deserves to
>>enter the geronimo team by hard work, and to accellerate someone due to
>>internship kind of breaks the rules and may cause some alienation in the
>>community...especially those who have spent time helping out and have
>>not been offered committership.
>>
>>I think the point of being a mentor is to help walk a person through the
>>process and how things are done...show the open source way and hopefully
>>have some cool code to show for it at the end of the day. But that
>>should be done without causing community heartburn.
>>
>>Here is an idea...
>>
>>What about an Apache "Summer of Code" ACL for SVN? This allows the
>>intern to not be an actual committer, but allows them to get the SVN
>>feel on an opensource project. It would offer a good balance for being
>>a mentor without causing bad feelings for those who have contributed and
>>have not been offered committership. What do you think?
>>
>>Jeff
>>
>>Aaron Mulder wrote:
>>
>>
>>>All,
>>>
>>> I volunteered to be a mentor for the Google Summer of Code, and
>>>there were a number of applications for Geronimo. I'm hopeful that at
>>>least one of them will be accepted.
>>>
>>> If that happens, we need to decide how to treat the student for
>>>the duration of the project (in terms of committership). This is kind of
>>>a special case in that the program is only a little over 2 months long,
>>>which means normally we probably wouldn't have made the person a committer
>>>in that time frame. But given that one of the goals is to teach the
>>>person how to contribute to open source, it seems to me like we wouldn't
>>>be doing them justice if we didn't give them commit for at least part of
>>>the project.
>>>
>>> I'd propose that if this goes through, we put the student on an
>>>"accelerated plan" where we have them contribute their initial work via
>>>patches, review and provide feedback, and then if all goes well offer them
>>>commit within the first 2-4 weeks. We will then need to evaluate their
>>>situation at the end of the program (both their contributions and their
>>>availability to work with us in the future) and decide whether to end
>>>their commit status or not (without any prejudice if we do decide to end
>>>it for whatever reason).
>>>
>>> So I'd love to get everyone's feedback on whether this seems OK.
>>>I specifically want this to be a "special case" -- I don't want to apply
>>>this to anyone else. I understand that there are a lot of people in the
>>>community who work hard and contribute and have not been offered commit,
>>>and I don't want to offend anyone or make anyone feel underappreciated,
>>>but I do personally feel like mentoring a student to be a future open
>>>source developer under the terms of this program requires more than simply
>>>asking them to submit patches.
>>>
>>> Let me know!
>>>
>>>Thanks,
>>> Aaron
>>>
>>>
Re: Google Summer of Code
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Jeff,
I'm open to the approach you recommend. But I still believe that
to really teach someone about open source, they need to hold commit on
something, and be able to break the build and get yelled at, and so on.
If we want to make it clear this is a non-traditional path, we could
decide to automatically remove commit privileges at the end of the
project. I'd prefer that we give them the experience and then take it
away, rather than convince them that the sole function of an open source
developer is to maintain their own source tree and submit patches. I
guess I'm trying to cram a 1-year experience into a 2-month microcosm.
But I also agree that we shouldn't frame this as the standard practice for
interns.
Anyone else out there have an opinion?
Thanks,
Aaron
On Wed, 22 Jun 2005, Jeff Genender wrote:
> Aaron,
>
> Thanks for stepping up and accepting this.
>
> My only .02 on this is you have to be careful about this accellerated
> role, and here is why...
>
> In open source, there is no age limit. In fact I believe one of the
> main/lead Firefox committers was in his early teens...so committership
> should not be offered just because someone becomes an intern. Due to
> the fact we have no barrier to entry, including age, nothing prevents a
> person from becoming a committer on thier own merits. Anyone can
> contribute and play in the sandbox.
>
> My point really is that we have a community that everyone deserves to
> enter the geronimo team by hard work, and to accellerate someone due to
> internship kind of breaks the rules and may cause some alienation in the
> community...especially those who have spent time helping out and have
> not been offered committership.
>
> I think the point of being a mentor is to help walk a person through the
> process and how things are done...show the open source way and hopefully
> have some cool code to show for it at the end of the day. But that
> should be done without causing community heartburn.
>
> Here is an idea...
>
> What about an Apache "Summer of Code" ACL for SVN? This allows the
> intern to not be an actual committer, but allows them to get the SVN
> feel on an opensource project. It would offer a good balance for being
> a mentor without causing bad feelings for those who have contributed and
> have not been offered committership. What do you think?
>
> Jeff
>
> Aaron Mulder wrote:
> > All,
> >
> > I volunteered to be a mentor for the Google Summer of Code, and
> > there were a number of applications for Geronimo. I'm hopeful that at
> > least one of them will be accepted.
> >
> > If that happens, we need to decide how to treat the student for
> > the duration of the project (in terms of committership). This is kind of
> > a special case in that the program is only a little over 2 months long,
> > which means normally we probably wouldn't have made the person a committer
> > in that time frame. But given that one of the goals is to teach the
> > person how to contribute to open source, it seems to me like we wouldn't
> > be doing them justice if we didn't give them commit for at least part of
> > the project.
> >
> > I'd propose that if this goes through, we put the student on an
> > "accelerated plan" where we have them contribute their initial work via
> > patches, review and provide feedback, and then if all goes well offer them
> > commit within the first 2-4 weeks. We will then need to evaluate their
> > situation at the end of the program (both their contributions and their
> > availability to work with us in the future) and decide whether to end
> > their commit status or not (without any prejudice if we do decide to end
> > it for whatever reason).
> >
> > So I'd love to get everyone's feedback on whether this seems OK.
> > I specifically want this to be a "special case" -- I don't want to apply
> > this to anyone else. I understand that there are a lot of people in the
> > community who work hard and contribute and have not been offered commit,
> > and I don't want to offend anyone or make anyone feel underappreciated,
> > but I do personally feel like mentoring a student to be a future open
> > source developer under the terms of this program requires more than simply
> > asking them to submit patches.
> >
> > Let me know!
> >
> > Thanks,
> > Aaron
>