Re: GSoC 2014: Summary so far, discussion starter: how to improve?

[Junio C Hamano <gitster@pobox.com>]

Thomas Rast <tr@thomasrast.ch> writes:

> Theories
> ========
>
> These are the hypotheses that I have heard (mostly in [1] and [2]) as
> to what is bad about Git's prior GSoC participations.
>
> * Aiming far too high, focusing on cool/shiny projects with a large
>   impact.  This also affects the students, who tend to cluster around
>   the largest, shiniest project suggestions.
>
> * Diminishing returns: Git is too mature, with little low-hanging
>   fruit left, making such projects harder

This needs to be qualified. There probably are little low-hanging
fruit left that still are shiny and cool for a newcomer to tackle.
That does not mean there are little low-hanging fruits that would
help our users; there still are a lot. Just that they are not as
glamorous.

> * Projects are too political, progress depending on non-technical
>   arguments

I do not recall any such.

> * Scope creep: projects tend to get blocked on some bigger
>   refactoring/restructuring task that was not in the original
>   proposal.

I think that is a sign that the original proposal did not look
enough at the existing code, dreaming of a pie-in-the-sky shiny
features in a green-field setting. What needs to be done within the
constraint of the existing code (including a total rewrite, if
necessary, while keeping the project's codebase maintainable is part
of the healthy develpment.

> Ideas and Suggestions
> =====================
>
> These are mostly from [2].  There were some suggestions that we learn
> from Matthieu Moy's very successful student projects (eg. [4]).
>
> * View GSoC much more as a lot of work than free labor
> ...
> * Mentoring improvements:
>   - Always have a co-mentor
>   - Focus on social aspects (who to Cc, etc.)
>   - Nominate separate "review mentors" to ensure fast review cycles

Good.

> * Have students review some patches

I am not sure if this would help.

Reviewing the patches to find style violations and off-by-one errors
is relatively easy as it can be done with knowledge on a narrow
isolated part of the system. Reviewing the design to make sure that
the change fits the way how existing subsystems work, ranging from
the internal API implementation level to consistency a changed
behaviour is presented at the UI level, however, needs understanding
of the far wider entire project than only the parts of the system
the proposed change updates. It will be even more true if the chosen
topic is a cool/shiny one.