Re: Summer of Code 2007

From: Mike Kienenberger (
Date: Wed Mar 28 2007 - 10:52:17 EDT

  • Next message: Mike Kienenberger: "Re: Summer of Code 2007"


    I think this is really helpful. You should consider posting it to

    On 3/28/07, Kevin Menard <> wrote:
    > > -----Original Message-----
    > > From: Andrus Adamchik []
    > > Sent: Monday, March 26, 2007 11:01 AM
    > > To:
    > > 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 - 10:52:48 EDT