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:andru..bjectstyle.org]
>> Sent: Monday, March 26, 2007 11:01 AM
>> To: de..ayenne.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
>
This archive was generated by hypermail 2.0.0 : Wed Mar 28 2007 - 12:04:19 EDT