Sitting on my flight back from the mentor summit at Google HQ seems to boost my writing power. Although I wanted to get some coding done, I’m mainly writing E-Mail. But I digress, cause I wanna take the chance to summarize a couple of ideas and compile a list of lesson learned items which floated around in the various sessions. Btw. it was an awesome event and I’m really grateful that I could attend it as an Eclipse rep.

Application review phase:

• Get the applications in a lot earlier to have a longer review period

• Assign mentors and students based on technical but also on social grounds

• Have direct, non text base communication (if possible video)

• Find a hook to the reptilian brain (imprinting) to understand how the student ticks

• If you as a mentor are euphoric about the student and the application, let somebody else do a review as well. The review process should be unbiased

• Most successful apps came from the student!!!

• Check how many alterations have been done to the app. The more alterations there are, the more thought has been given by the candidate

• Let the candidate take an entry level test if his/her abilities aren’t known to the reviewer

Community building:

• It should be mandatory to hang out on IRC, IM or whatever communication form is most common. In our case it is probably IRC

• After accepting the students and assigning them to their mentor, do a big group introduction. Again, it shouldn’t be text based

• Have the formal things done fast. It is really frustrating to wait weeks for commit access to the SoC repository

Monitoring and rating progress:

• Define precise project deliverables upfront, though they might change over time

• Frequent checkins should be mandatory. If there is no checkin in a week, find out what’s going on

• Have a transparent review process by providing check-in statistics (DASH/CIA/…)

• Sidenote: Expand DASH to not just monitor CVS/SVN but to also gather statistics about contributions out of Bugzilla, newsgroups and mailinglists…

• Let the student take the test driven development model

After the term ends:

• If all deliverables have been successfully solved by the student, have some follow up tasks in the pocket to keep the student involved with the project. In the end she/he should become a permanent contributor/committer

This collection is certainly far from being complete. This said, the moment the official session notes will be made available, I will add a link to this post. They are currently kept in the non public GSoC wiki.