My GSoC2014 retrospective

My GSoC2014 retrospective

[Matthieu Moy]

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/

Re: My GSoC2014 retrospective

[Junio C Hamano]

Thanks for a write-up. FWIW, I also did enjoy interacting with your student.

On Mon, Sep 8, 2014 at 2:10 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> 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/