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.