Re: Summer of Code 2007

[Andrus Adamchik]

Hi Kevin,

Thanks for the thoughts! I agree with most of your suggestions on  
improving the process.

And sorry for the rant that follows your very constructive email :-)

I've been thinking about it some more, and IMO the problem is at a  
more basic level. SoC is a PR action by Google and participating orgs  
(including ASF), and as such for the student it does not follows ESR  
paradigm of scratching a personal itch.

I have lots of examples that validate ESR rule. Here is a negative  
one from recent Cayenne history - I had 4 different very qualified  
developers who don't know each other, who at different times  
privately expressed interest in participating in JPA work. I guess  
because they thought it is a cool thing to do? How many actually  
contributed - zero. My explanation is that they don't use JPA, so  
they don't care about JPA. If they did, they would've figured a way  
to contribute.

And I see a parallel here - students who don't use Cayenne in their  
work (there are students who do use Cayenne) is temp labour paid by  
Google with no interest in the technology or the community. I am sure  
if the opposite was true, current Apache process would've worked just  
fine. In 2006 we had one project that was forced to use the mailing  
list and patches, and another one that wasn't (and one more that was  
half-way in between) - the results all were the same, confirming my  
suspicions.

I really don't see a way out of this contradiction, therefore I am  
not enthusiastic about mentoring this year.

Andrus



On Mar 28, 2007, at 6:07 PM, Kevin Menard wrote:

-----Original Message-----
From: Andrus Adamchik [mailto:[EMAIL PROTECTED]
Sent: Monday, March 26, 2007 11:01 AM
To: dev@cayenne.apache.org
Subject: Re: Summer of Code 2007

Yep.

BTW, Kevin, do you have any insights from the last year
Google mentor summit that may be helpful for us this year?

Andrus

I'm having a hard time thinking of anything truly insightful.   
However,
it would be beneficial to both students and mentors to come up with a
realistic way of completing these projects.  I know you and I had very
different viewpoints on this, and it's unfortunate that there  
wasn't any
resolution on it.  In fact, I think it may even be a fundamental issue
with the ASF process that puts significant hurdles in front of  
students.

A few of the problems that come to mind (numbered, but not necessarily
ordered):

1) Cultural differences (both regionally and organizationally) --  
One of
my students didn't get out of school until about a full month after  
the
program started.  It obviously created a fair amount of difficulty in
completing the project in a timely manner.  Being in a distant  
timezone
hampered communications quite a bit as well.  I found for one student,
instant gratification was something often sought after and that also
affected the way we communicated.

Organizationally, the ASF presents quite a shift from the way students
are accustomed to doing things.  Teaching them new methods is of  
course
fine, but given the limited time given to start with, it minimized  
what
could actually be accomplished.  Other differences are noted below.

2) Code contributions -- Students really should be given the proper
tools to do development, including an SCM.  We don't just hand commit
privileges out, so this creates a bit of a divide.  Last year, we
encouraged students to submit patches via JIRA, but this created more
problems than it resolved, IMHO.  It's hard to provide a patch file  
for
truly new resources.  And it's even harder to get students to submit a
patch to a patch (or update the old one) to meet our submission  
criteria
-- this is especially true if the student has a local development
environment that doesn't necessarily line up with a patch.  What I  
found
is that the patches submitted for my projects tended to languish in  
some
odd state.  They weren't quite ready to be committed, but the student
couldn't quite update them from their local dev environments because
they had added completely orthogonal bits of code since the time the
first patch was submitted.  In my case, I ended up with large patches
consisting of the whole project that I had to try to review towards  
the
end of the project.

My recommendation would be to make an exception for SoC students from
the normal ASF process and create a branch for them that they can  
commit
against.  Likewise, we should really enforce the signing of a CLA  
on the
outset.

3) Communication -- We promote mailing lists.  One of my students last
year very much preferred the use of AIM.  I encouraged the use of the
mailing lists throughout the whole summer, but it never quite  
happened.
I did, however, have plenty of IM conversations.  So, on the one hand,
it sucked it wasn't "open", but on the other, I'd prefer that than no
communication at all.

Also, I'm not sure mailing lists for everything is most appropriate.
Regardless of how we treat things organizationally, to the student,  
the
assigned mentor is the mentor, not the dev list.  I had many candid
conversations with one of my students that probably would have played
out very differently in a public forum.  Being able to help the  
student
out in that manner was personally more fulfilling to me than  
serving as
a KB on cayenne internals.


All in all, I found the experience to be quite rewarding, although the
benefits to Cayenne as whole have yet to really be seen.  I think
dealing with a lot of the logistical issues in advance would have made
life easier for student and mentor alike.  I know we tried to deal  
with
some of them on the code-awards list last year, but there was no
concensus across projects.

I do have some suggestions on a few things, some of which are inspired
from the SoC conference last year, but I'll save those for a more
in-depth discussion.

Hopefully that long unintelligible rambling helps someone . . .

--
Kevin