Kevin,
I think this is really helpful. You should consider posting it to
communit..pache.org.
On 3/28/07, Kevin Menard <kmenar..ervprise.com> 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 - 10:52:48 EDT