Stefan Beller <sbel...@google.com> writes:
> On Wed, Sep 2, 2015 at 10:58 AM, Junio C Hamano <gits...@pobox.com> wrote:
>
>> * The individual qualities of the students we got this year must
>> have been a major factor. This we can indirectly influence by
>> having a very engaging microproject period, I think, and we did
>> so this year.
For sure, having good students does help ;-).
Note that "good" students is not just a matter of technical skills, but
also largely a matter of motivation, perseverance & so. I remember in
past years students for which we had very high hopes and who lost
interest in the GSoC during the summer.
It's actually very hard to identify good students before the project. My
experience (in GSoC and elsewhere) is that the correlation between how
well we rate the student in the selection period and how it actually
goas afterwards is weak (or sometimes, there is a correlation, but with
a negative slope!).
Microprojects are a very good way to improve this correlation, and at
least to eliminate really bad students quickly. We had 11 proposals this
year, and we really discussed about 3 or 4 of them, others were
discarded early.
Microprojects also give students a taste of what "contributing to Git"
means. As a consequence, the "community bonding period" is essentially
useless: it's already done. As mentors, we did give a few advices to
Karthik during that period, but essentially on the way to manage his own
project, as he already knew the community.
>> * I cannot say anything about mentor-student interactions, which
>> are largely private. Mentors may want to share tips to get
>> students more engaged, or perhaps the level of engagement was
>> primarily affected by who the students were. I dunno.
>
> As a first time mentor, I sometimes had the feeling of not doing enough
> mentoring. Though maybe just because of less private student-mentor
> interaction the reviews came to the list earlier exposing the patches to
> a wider audience?
Actually, I think a good mentor-student relation is to avoid
mentor-student relation ;-).
On our side, we exchanged a few emails. We have a private thread with 29
emails, most of them very short. We did sometimes pre-review: add a few
comments on a draft on GitHub before sending to the list, to save other
reviewers some time on easy-to-catch mistakes, but the important
discussions were done on-list.
Quite often, the on-list consensus was proving my off-list remarks
wrong, but the time lapse between my incorrect statement and the
correction by the list was short, and thanks to this, not much time was
lost. Much better than spending the summer working on incorrect
statements or speculations on what the actual review will look like.
>> * The topics chosen this year were well-sized, not overly nebulous.
Interestingly, both projects were essentially internal refactoring ones
(the one I mentored last year was, too). Nothing really impressive for
the end-user, but in both cases a substantial contribution to Git's
maintainability.
I'm positively surprised that students chose these topics. They are not
the best subjects to show off with your friends ("see this new command
you love so much, *I* implemented it!"), but are necessary work to make
the codebase healthier.
The tempting trap we avoided is the flashy project ending up with a very
impressive prototype that no one wants to maintain.
IOW, I think we decreased the technical debt of Git, while we gave into
the temptation of increasing it in the past.
>> * The reviewers were helpful and probably more active than past
>> years.
For Karthik (I didn't follow Paul enough to say), reviewers did a really
great job. Especially Junio and Eric, but many other helped too. I was
amazed by the amount of change from iteration to iteration.
I'd add one item:
* We limited the number of slots. A successful GSoC has to be a lot of
work for many people (student, mentor, reviewer, maintainer). We have
a limited bandwidth to deal with the GSoC, and I think that focusing
on a small number of slots is a good strategy.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
