| 1 | = Summer of Code Discussions = |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | == Screening and pre-program concerns == |
| 6 | |
| 7 | === Project definitions === |
| 8 | |
| 9 | * '''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. |
| 10 | |
| 11 | === Student commitment === |
| 12 | |
| 13 | * '''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. |
| 14 | * '''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. |
| 15 | |
| 16 | == Student/mentor interaction and operation == |
| 17 | |
| 18 | === Practices which have worked === |
| 19 | |
| 20 | * '''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". |
| 21 | |
| 22 | === Practices which should be encouraged (required?) === |
| 23 | |
| 24 | * '''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. |
| 25 | * '''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. |