Re: GSoC 2014: Summary so far, discussion starter: how to improve?
- From
Fredrik Gustafsson <iveqy@iveqy.com>
- Date
- Oct 19, 2013, 21:51 UTC
- Message-ID
- <20131019215139.GX13967@paksenarrion.iveqy.com>
- In-Reply-To
- <8761stx04i.fsf@linux-k42r.v.cablecom.net>
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:
Show 28 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 > > * 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.
Show 5 quoted lines
> > * 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.
Show 5 quoted lines
> > * 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