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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 22, 2013, 21:31 UTC
Message-ID: <xmqqli1lro08.fsf@gitster.dls.corp.google.com>
In-Reply-To: <8761stx04i.fsf@linux-k42r.v.cablecom.net>

Thomas Rast <tr@thomasrast.ch> writes:

Show 12 quoted lines

> 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.

Show 12 quoted lines

> 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.