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

[Fredrik Gustafsson <iveqy@iveqy.com>]

Hi,
so I was a GSoC:er, I got some (most) of my code merged but didn't fully
met my (personal) goals for the project. However I do passed in the eyes
of Google.

GSoC is _hard_. You end up feeling completely stupid over and over
again. Git has hard standards. Beeing just a single programmer and/or
just learnt programming in school, there's a lot of difference.

I started with learning git (better), read documentation and looking
at the codebase and still felt lost.

After that I'd to learn communication skills, who to mail, when to mail,
how to write a commit message, been real strict with codestyle,
setting up a github account, configuring git in a "git contributor
friendly way", etc.

On Sat, Oct 19, 2013 at 08:09:33AM +0200, Thomas Rast wrote:
> 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
> 
> * Projects are too political, progress depending on non-technical
>   arguments
> 
> * Our mentors suck on various axes, notably not supporting students
>   enough in things that matter:
>   - smooth interaction with community
>   - ensure fast iteration/short cycles
>   - navigating the code base
> 
> * Scope creep: projects tend to get blocked on some bigger
>   refactoring/restructuring task that was not in the original proposal
> 
> 
> 
> * View GSoC much more as a lot of work than free labor

Totally agree, GSoC is an investment for future labor, not labor.

> 
> * Break projects into smaller, easier tasks
>   - They should individually be simple, quick things if the mentor did
>     them.
>   - Should be parallelizable so students don't have to block on reviews.

I'd 5-6 smaller projects setup for the summer, I think I managed to do
2-3 of them. (I did however do everything I applied for). I really think
it's an excellent idea. This also meant that while one patch waited for
review, I'd other things to work on.

> 
> * Mentoring improvements:
>   - Always have a co-mentor
>   - Focus on social aspects (who to Cc, etc.)
>   - Nominate separate "review mentors" to ensure fast review cycles

I like the idea of review mentors. However bear in mind that you'll
already have three people reviewing the patches (two mentors and Junio).
We will not make it look like it's impossible to get things into
git.git.

> * Have students review some patches

This would be excellent. That's a part that I thinks is very usefull and
would easy students remaining with git. It's easier to review patches
than to make them.


As a last part I would say that GSoC learned me a lot. I'm good at git,
I know test driven development, I learned shell, I got to play with a
huge C-codebase for the first time and I learned open source projects,
QA, etc.

I would like to thank Jens and Heiko for good mentoring and a lot of
patience!

(as a sidenote, I did get extremly busy when the school started. I
didn't even had time to fix a serious bug in my code (Jens had to clean
up after me). However two years later I'd some time again and got a few
patches in and I hope to get a few patches into git in the future too).

A successful GSoC for git isn't a merged project but continued
contribution to git (not necessairly in patches, but also in support and
review).

A successful GSoC for Google/student is a merged project.

A successful GSoC for student is a great learning experience.
-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com