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