RE: Summer of Code 2007

From: Kevin Menard (
Date: Wed Mar 28 2007 - 10:07:34 EDT

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

    > -----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

    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

    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 . . .


    This archive was generated by hypermail 2.0.0 : Wed Mar 28 2007 - 10:11:55 EDT