Summer of Code Discussions

To date, Summer of Code organization for Pidgin has been rather ad-hoc, building on the previous year's successes and failures in an organic fashion. While this has worked reasonably well, it appears that there is room for improvement by documenting the lessons learned, and discussing them prior to our next participation in SoC. Note that none of the comments here are intended to reflect upon a particular mentor, student, or project; in fact, several of the initial comments come from viewing SoC projects in general from the outside.

Screening and pre-program concerns

Project definitions

• Project scope and goals: These need to be clearly defined a priori; we have more than once run afoul of unclear progress due to fuzzy project definitions.
• Large projects: For very large projects, e.g., a whole new UI or a language binding for libpurple, applicant should include a lot of technical details. Some mock-ups, sample proof-of-concept implementations can also be helpful in judging the strength of the application.

Student commitment

• Projected time commitment: Students should specify clearly the amount of time they expect to work on the project per day/per week/etc. Known schedule conflicts (vacations, large school projects, etc.) should be declared up front. SoC is intended to compare to a full-time summer job, and we should expect students to make a corresponding commitment.
• Conflicting commitments: Other jobs (or even job applications!) need to be declared so they they can be weighed. It seems like we lose a few students every summer to other jobs and commitments -- this costs us a slot in the program, as well as costing Google the $500 up-front payment. This is not really acceptable, and one would hope that students would be responsible enough to avoid it, but it happens.

Student/mentor interaction and operation

Practices which have worked

• Student blogs or wiki pages, updated at least weekly: Not only does this increase visibility outside of the student/mentor team, but it helps the mentor keep track of progress with an eye for "what is happening", versus "what do I think is happening".

Practices which should be encouraged (required?)

• Introduce yourself: Students should send an email to the devel mailing list and introduce themselves and explain what they're working on.
• Public communication: Students should be encouraged to take as much interaction as possible to the public mailing list, XMPP MUC, or IRC channel. Not only are private communications less in the "spirit of open source", but they make it more difficult for other mentors and project participants to keep track of progress.
• Mailing list status reports: "Push" status is helpful for those who are not following a particular SoC project closely, but may be affected by its progress in ways they did not anticipate.
• News posts on pidgin.im: We haven't done this in the past, but posting an overview of all SoC projects on the pidgin.im News page would promote SoC and help motivate our students.