You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by Kevin Menard <km...@servprise.com> on 2006/10/12 17:45:53 UTC
[Fwd: Google Summer of Code Summit]
Sorry if this went through before, since there were issues with my list
subscription. If not, please feel free to share your thoughts, as the
Google SoC summit is in two days. I'll be flying most of tomorrow, but
should be able to gather everything together tomorrow night.
Best regards,
Kevin
-------- Original Message --------
Subject: Google Summer of Code Summit
Date: Wed, 04 Oct 2006 13:50:25 -0400
From: Kevin Menard <km...@servprise.com>
To: community@apache.org
Hi all,
As I'm sure most of you are aware, the ASF partook in the Google Summer
of Code (SoC) program again this year. We were granted 28 student
projects, across a variety of ASF projects. Since the program has just
recently finished for the year, we should hopefully start seeing some of
that work integrated into the project codebases.
Anyway, Google has been gracious enough to host an SoC summit, offering
to pay travel for two representatives from each organization. Ross
Gardler and I will be attending on behalf of the ASF. The format of the
summit is going to be largely user-driven and likely will cover an
assortment of topics related to the SoC program itself. What I'd like
to do is solicit feedback from the ASF community in general so I can
bring that to the table.
SoC is an interesting program. The focus should be on the students and
ensuring that they have an enriching experience. The goal should be to
introduce them to OS development and best practices. Sometimes this is
lost as projects try to get more "free work", so to speak. Just to
clarify, there's nothing wrong with having students work on something
that can be useful to a project, but the emphasis should be on the
student, not the project. In general, I think the ASF understands this
and that the mentors did an excellent job. Surely, as a group, we could
stand to do a little better though. So, having said that, I'm going to
kick this off with a few questions and please feel free to add your own:
o Is SoC a worthwhile program?
o Should the ASF continue to participate in the SoC program?
o How can the ASF improve the student experience?
o How should the ASF use student projects?
o Should students be given more development resources than non-committers?
Anyway, you should get the general point. I'm seeking either positive
or negative criticism, so long as its constructive.
Thanks a lot,
Kevin
--
Kevin Menard
Servprise International, Inc.
"Remote reboot without pulling the plug" -- http://www.servprise.com
--
Kevin Menard
Servprise International, Inc.
"Remote reboot without pulling the plug" -- http://www.servprise.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [Fwd: Google Summer of Code Summit]
Posted by Bertrand Delacretaz <bd...@apache.org>.
> o Is SoC a worthwhile program?
Yes, no question about this. In Cocoon and FOP, SoC brought us at
least two very good committers in 2005 and 2006, who might not have
joined the projects otherwise.
> o Should the ASF continue to participate in the SoC program?
Sure!
> o How can the ASF improve the student experience?
By being very careful about the student selection - it is much better
to have the "wrong" students fail very early in the process.
>From what I've seen (I was a mentor last year, not this year), we
should only accept students who have been actively doing something to
"connect" with our communities before the program starts. Others
usually don't get the way we work, or get it much too late to do
anything useful.
> o How should the ASF use student projects?
If student's projects can be integrated directly in our codebase
that's very cool. But in some cases this can also be an opportunity to
try wild things which have little chance or being directly useful.
> o Should students be given more development resources than non-committers?
Last year in the Cocoon project we opened an area of our SVN
whiteboard (experimental zone) for the students, IMHO this was very
good: it allowed us to see their progress in real time and it helped
them learn the right way to work with a shared repository. If we want
them to work full time on the project we have to give them good tools,
IMHO.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [Fwd: Google Summer of Code Summit]
Posted by Kevin Menard <km...@servprise.com>.
Andrus Adamchik wrote:
> No firefight - there is simply no other way to build karma on an open
> source project. And the fact that one of our projects was done with no
> community involvement simply sucks.
>
My point was that if some sort of distributed SCM was used rather than
SVN, then it wouldn't matter that much at all. Non-committers (in this
case, the students) would still be able to pull and update from the main
codebase while committing locally. They'd get the benefits of having
some sort of endorsed code management system that they could easily
generate patches from. The idea of SVK was batted around on the mentor
list, but didn't get very far. Cayenne tried two different SVN
installations, which made it rather difficult to keep on top of
patches. Others used no SCM at all.
Anyway, to get back where this started. Did we give the students
everything they needed to work most effectively and productively? If
so, then JIRA patches are the way to go for next year. If not, what
could be done differently?
--
Kevin Menard
Servprise International, Inc.
"Remote reboot without pulling the plug" -- http://www.servprise.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [Fwd: Google Summer of Code Summit]
Posted by Andrus Adamchik <aa...@apache.org>.
On Oct 12, 2006, at 1:35 PM, Kevin Menard wrote:
>>> o Should students be given more development resources than non-
>>> committers?
>>>
>>
>> -1
>>
>
> This goes a bit in hand with the previous discourse on patches.
> This could quickly degrade into a procedural firefight, but it does
> sorta irk me that we expect people to give us code, but don't give
> them adequate tools to do it. If I ever applied for a job
> somewhere and they told me the only tools I had for submitting code
> were diff and JIRA, I'd hazard to say I wouldn't be at that job
> very long. There's something of a culture of earning the right to
> commit, and for the main codebase I'd say it's warranted. For a
> throw away branch, however, it seems to me like an unnecessary
> hurdle that we put in the way of students completing their work.
No firefight - there is simply no other way to build karma on an open
source project. And the fact that one of our projects was done with
no community involvement simply sucks.
Andrus
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [Fwd: Google Summer of Code Summit]
Posted by Kevin Menard <km...@servprise.com>.
For this and other emails in the thread, I'm going to switch hats from
my role of solicitor to one of fellow mentor. This is mostly to
stimulate more conversation. I will do my best to represent all
viewpoints fairly in the end, however.
Andrus Adamchik wrote:
>> Sorry if this went through before, since there were issues with my
>> list subscription.
>
> AFAIK it didn't - this is the first copy that I received.
Well, then that certainly sucks. Thanks for letting me know.
> I disagree. You are right about the goals, but you are wrong about the
> focus. Two reasons:
>
> 1. *Abstract* altruistic motives (on the mentors part) don't work. It
> has to a be a *specific* altruistic (or not) motive for anyone to
> participate in that.
>
> 2. From my own student years and a few internship-type projects that
> I've done back then (more than a few years ago to be sure) - the most
> discouraging part is a hypocrisy of being told that you are working on
> a "real thing", only to realize later that you were doing something
> that nobody ever intended to use. This is the most certain way to kill
> enthusiasm.
Heh. My own experience is that it can be really discouraging to just do
all the crap work no one else wanted to do. Although, if SoC is to be
like an internship, maybe it's not too far off the mark.
>> o How can the ASF improve the student experience?
>
> Make sure the patches are reviewed and committed promptly.
In my own experience, this turned out to be much easier said than done.
The easiest patches to review are the small ones. Since many students
essentially start from scratch, they're patches aren't exactly small
ones to begin with. Sure, they could provide patches that do nothing,
but no one wants incomplete patches either. Based on mentor feedback,
the codebase may change considerably, and then the next submission is a
patch against an old patch that's so radically different, it may as well
have been a new submission to begin with. More on this below.
>> o How should the ASF use student projects?
>
> Depends on the project. Ideally it should be clear at the proposal
> stage where the code would fit in.
Agreed, but all too often things change.
> So while it is unreasonable to expect most of the students to stick
> around past the end of the program, my personal feeling is that we
> should only accept the proposals that we know how we can use, and
> actually ask the students to put "integration of the code in the
> product core" item on the proposal (see my comments above on the
> reasons why). Or was it already on a proposal? :-)
Heh. Once that secret's out, everyone will be using it in their
proposals ;-)
>> o Should students be given more development resources than non-
>> committers?
>
> -1
This goes a bit in hand with the previous discourse on patches. This
could quickly degrade into a procedural firefight, but it does sorta irk
me that we expect people to give us code, but don't give them adequate
tools to do it. If I ever applied for a job somewhere and they told me
the only tools I had for submitting code were diff and JIRA, I'd hazard
to say I wouldn't be at that job very long. There's something of a
culture of earning the right to commit, and for the main codebase I'd
say it's warranted. For a throw away branch, however, it seems to me
like an unnecessary hurdle that we put in the way of students completing
their work.
> I am glad we followed the advice from 2005 SoC mentors and didn't go
> that way. Still we diverted a bit by setting up the sandbox SVN
> outside Apache. The result was that 1 project never communicated
> anything to the community (I still have no idea what it does and how
> far it went in its development, as it was all done between the mentor
> and the student).
In my own experience, it's easier to stay on top of commit emails with
diffs than it is JIRA issues with attached patches *shrug*
--
Kevin Menard
Servprise International, Inc.
"Remote reboot without pulling the plug" -- http://www.servprise.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [Fwd: Google Summer of Code Summit]
Posted by Andrus Adamchik <aa...@apache.org>.
Hi Kevin,
> Sorry if this went through before, since there were issues with my
> list subscription.
AFAIK it didn't - this is the first copy that I received.
Here is my feedback as a mentor. I'll be talking about the three
projects that we handled in Cayenne this year, as I have no idea how
it worked out for the other 25.
> The focus should be on the students and ensuring that they have an
> enriching experience. The goal should be to introduce them to OS
> development and best practices. Sometimes this is lost as projects
> try to get more "free work", so to speak. Just to clarify, there's
> nothing wrong with having students work on something that can be
> useful to a project, but the emphasis should be on the student, not
> the project.
I disagree. You are right about the goals, but you are wrong about
the focus. Two reasons:
1. *Abstract* altruistic motives (on the mentors part) don't work. It
has to a be a *specific* altruistic (or not) motive for anyone to
participate in that.
2. From my own student years and a few internship-type projects that
I've done back then (more than a few years ago to be sure) - the most
discouraging part is a hypocrisy of being told that you are working
on a "real thing", only to realize later that you were doing
something that nobody ever intended to use. This is the most certain
way to kill enthusiasm.
> o How can the ASF improve the student experience?
Make sure the patches are reviewed and committed promptly.
> o How should the ASF use student projects?
Depends on the project. Ideally it should be clear at the proposal
stage where the code would fit in.
So while it is unreasonable to expect most of the students to stick
around past the end of the program, my personal feeling is that we
should only accept the proposals that we know how we can use, and
actually ask the students to put "integration of the code in the
product core" item on the proposal (see my comments above on the
reasons why). Or was it already on a proposal? :-)
> o Should students be given more development resources than non-
> committers?
-1
I am glad we followed the advice from 2005 SoC mentors and didn't go
that way. Still we diverted a bit by setting up the sandbox SVN
outside Apache. The result was that 1 project never communicated
anything to the community (I still have no idea what it does and how
far it went in its development, as it was all done between the mentor
and the student).
Andrus
On Oct 12, 2006, at 11:45 AM, Kevin Menard wrote:
> Sorry if this went through before, since there were issues with my
> list subscription. If not, please feel free to share your
> thoughts, as the Google SoC summit is in two days. I'll be flying
> most of tomorrow, but should be able to gather everything together
> tomorrow night.
>
> Best regards,
> Kevin
>
> -------- Original Message --------
> Subject: Google Summer of Code Summit
> Date: Wed, 04 Oct 2006 13:50:25 -0400
> From: Kevin Menard <km...@servprise.com>
> To: community@apache.org
>
>
>
> Hi all,
>
> As I'm sure most of you are aware, the ASF partook in the Google
> Summer of Code (SoC) program again this year. We were granted 28
> student projects, across a variety of ASF projects. Since the
> program has just recently finished for the year, we should
> hopefully start seeing some of that work integrated into the
> project codebases.
>
> Anyway, Google has been gracious enough to host an SoC summit,
> offering to pay travel for two representatives from each
> organization. Ross Gardler and I will be attending on behalf of
> the ASF. The format of the summit is going to be largely user-
> driven and likely will cover an assortment of topics related to the
> SoC program itself. What I'd like to do is solicit feedback from
> the ASF community in general so I can bring that to the table.
>
> SoC is an interesting program. The focus should be on the students
> and ensuring that they have an enriching experience. The goal
> should be to introduce them to OS development and best practices.
> Sometimes this is lost as projects try to get more "free work", so
> to speak. Just to clarify, there's nothing wrong with having
> students work on something that can be useful to a project, but the
> emphasis should be on the student, not the project. In general, I
> think the ASF understands this and that the mentors did an
> excellent job. Surely, as a group, we could stand to do a little
> better though. So, having said that, I'm going to kick this off
> with a few questions and please feel free to add your own:
>
> o Is SoC a worthwhile program?
> o Should the ASF continue to participate in the SoC program?
> o How can the ASF improve the student experience?
> o How should the ASF use student projects?
> o Should students be given more development resources than non-
> committers?
>
> Anyway, you should get the general point. I'm seeking either
> positive or negative criticism, so long as its constructive.
>
> Thanks a lot,
> Kevin
>
> --
> Kevin Menard
> Servprise International, Inc.
> "Remote reboot without pulling the plug" -- http://www.servprise.com
>
>
>
> --
> Kevin Menard
> Servprise International, Inc.
> "Remote reboot without pulling the plug" -- http://www.servprise.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org