Hi, So, GSoC 2014 is over, and it's time for me for a retrospective too. As a reminder, Git participated in GSoC a number of times, but we were not happy enough with how it went and did not apply in 2013. This year, we thought we would hopefuly be better at mentoring students, and gave one more try. It was my first experience as a GSoC mentor, although I supervised students my engineering school contributing to Git as a school project several times. On overall, Git selected 3 students, one of them did not send anything to the list and failed the mid-term. Fabian worked on rebase -i improvements, send several versions of his patch series, but the code did not reach pu (yet?). I mentored Tanay, who worked on git_config improvements with the help of Ram. As Tanay wrote in his retrospective [1], there's a reasonable amount of code merged (next or pu). All the objectives of the project have not been reached, but I still consider it as a relative success. I prefer by far having this situation than having everything half-done and nothing merged. [1] http://permalink.gmane.org/gmane.comp.version-control.git/256458 I think the following contributed to this (I'll talk about my experience, don't try to see a comparison with others or any over-generalization): Microprojects ------------- Microprojects were a really, really good idea. Far better than selecting students only based on their proposal on melange and a superficial discussions in the comments below the proposals. And not only for selection: students learnt the contents of SubmittingPatches before starting the project, so that was one less thing for me to teach as a mentor, and less opportunities for mistakes in the first iterations. On-list interaction ------------------- According to my email archives, there are 106 threads where I sent an email to Tanay, 83 of which happened on-list (and 64 are followups to a PATCH). The off-list exchanges were essentially quick reviews of draft series, and short messages to give an advice. I think its very important to have this on-list interaction for many reasons. It's good, make sure everybody has an opportunity to give his or her opinion about the project soon (as a mentor, I can obviously be wrong, and the sooner someone notices it, the less time lost). It's good for the student, because GSoC is all about interacting with a community, not just with a mentor. And, well, it has to be good because this is how we usually work here. OTOH, we should probably have exchanged a few emails in private between GSoC mentors and admin. I wasn't really aware of what other students were doing except what they sent to the list, and it could have helped to know a bit more about how others were doing. Also, I insisted with Tanay that he should introduce himself on the list, and remind people that he was working as a GSoC student when he sent his first patch. I realized how much this was important when I discovered in a private conversation that Junio did not know that Fabian's series was sent as a GSoC project. While I don't think "I'm sending this patch as part of my GSoC" should be equivalent to "please, merge this even if the code is not good, I'm still a student after all", I think is helps reviewers to know about GSoC, if only to better advise the student. Code merged ASAP ---------------- I think Tanay and I did a good job at getting some code merged early. We did bother Junio a bit with series depending on each other, but we could send code by relatively small series, and prioritized "finish first series" over "start new ones". Of course, reviews take time, so we still had several series in parallel, but splitting the work like this allowed some code to reach master early, while part of the work is still unfinished. We all hope that GSoC students will remain part of the community, and it's tempting to think that unfinished code isn't a problem because we will have time to finish it later, but I think it's risky. My motto for this kind of projects (I do the same with Ensimag students): hope that students will keep contributing after the end, but don't rely on it. Mentoring takes time -------------------- I knew it (and actually, I was initially reluctant to be a mentor for this reason), but I did enjoy the experience and happily spent a lot of time and energy on it. Most series needed many iterations, and we couldn't have reached the quality required to get in git.git without fast and detailed reviews. I did my best to review the code ASAP when a series was sent, and fortunately the list, and Junio in particular, was very supportive. Thanks a lot to everybody who contributed! Still, I think it should have taken less iterations to get the final result. But I do not know what we could have done better for that. In the end ... -------------- My goals with the GSoC were essentially (unordered): * Teach cool stuff to a student (for those who missed it, I'm a teacher in another life ^^) * Get useful code in git.git * Attract new long-term contributors * Have fun I think each of them is satisfied. The future will tell us if the third one is actually reached, but Tanay's motivation was also to start contributing on a regalar basis, and I hope we all motivated him to do so! -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html