Re: Google Summer of Code 2013 (GSoC13)

From: Jeff King <peff@peff.net>
Date: Feb 18, 2013, 18:58 UTC
Message-ID: <20130218185801.GA25673@sigill.intra.peff.net>
In-Reply-To: <CALkWK0nDEwgDwnVktmM8abv3ZgQmJCOm8LBe25UKR485PZMPfA@mail.gmail.com>

On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote:

Show 8 quoted lines

> I'll be frank here.  I think the main reason for a student to stick
> around is to see more of his code hit `master`.  I think it is
> absolutely essential to get students constantly post iteration after
> iteration on the list. It would be nice to get them connected with 2~3
> people in the community who will follow their progress and pitch in
> everytime they post an iteration.  It might also make sense to stage
> their work in the main tree (a gsoc/ namespace?), so we can just
> checkout to their branch to demo what they've done.

I agree. One of the main problems with GSoC projects is that the student goes away and works for a while, and then at the end does not necessarily have something mergeable. That is not how regular contributors work. They post works in progress, get feedback, and iterate on ideas. They break work into easily digestable and reviewable chunks. So maybe the mentors should be focusing more on that than on actual code problems.

Show 5 quoted lines

> Also, we need more projects that will scratch everyday itches.  A
> collection of related tiny features might not be a bad idea.  Often,
> we risk erring on the side of too-big-for-one-summer when it comes to
> specifying projects.  What's the harm of including something estimated
> to take 80% of a summer?

I very much agree with you here. One problem is that those smaller projects often do not sound as grand or as interesting, and so students do not propose them. We have to work with the applicants we get.

> On a related note, I don't like our Wiki.  It's down half the time,
> and it's very badly maintained.  I want to write content for our Wiki
> from the comfort of my editor, with version control aiding me.  And I
> can't stand archaic WikiText.

Agreed on all of those points. Putting the Wiki on GitHub fixes that. But it means contributors need to have a GitHub account. On the other hand, I think kernel.org wiki contributors need an account these days? And GitHub is putting some active effort into finding and killing spammy accounts, which might keep wiki spam down (I do not pay too much attention to those efforts, but on kernel.org, it is mostly up to the Git community to do it ourselves).

-Peff