Re: Google Summer of Code 2013 (GSoC13)

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Feb 19, 2013, 09:00 UTC
Message-ID: <CALkWK0kdjKXAiOz6k-Anfb3Xut5apZbQ-rqYhkA73YRu83tLcw@mail.gmail.com>
In-Reply-To: <20130218211321.GD27308@sigill.intra.peff.net>

Jeff King wrote:

Show 20 quoted lines

> On Tue, Feb 19, 2013 at 01:15:49AM +0530, Ramkumar Ramachandra wrote:
>
>> Take what I'm about to say with a pinch of salt, because I've never mentored.
>>
>> Mentors often don't provide much technical assistance: students should
>> just post to the list with queries, or ask on #git-devel.  Mentors
>> serve a different purpose; their primary responsibility, in my
>> opinion, is to teach the student a sustainable productive workflow.
>> This means: profiling them to figure out where they're losing out.  Do
>> they have the habit of:
>> - posting to the list regularly?
>> - CC'ing the right people?
>> - iterating quickly after reviews?
>> - using gdb efficiently to quickly understand parts?
>> - using git efficiently for the rebase/ patch workflow?
>
> I think you are spot-on. Those are the things that students need to
> learn to do, and what mentors should be pushing them towards. But it
> seems like we have the same problems with it year after year, and I know
> mentors have worked on it. I'm not sure where the problem is.

I essentially have a couple of suggestions:
- Be more thorough about discussing proposals; pick mentors from those
who are deeply involved in the discussion, and are interested in the
student.
- Increase the visibility of every GSoC project in the community.
Like I suggested earlier, a set of GSoC branches in-tree would be a
great start: it's easy to go through the `log`, and tell if the
student has been idle for a while.  We can put up links to the GitHub
graphs for each of these branches.

Show 12 quoted lines

>> > 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.
>>
>> We have to post well-crafted proposals like this to pique their interest.
>
> True. I think we can bear some of the blame in the proposal writing. But
> if you look at the applications each year, they tend to cluster around
> one or two projects, and most projects get no hits at all. It could be
> because they're badly written. But I think it is also that they are not
> in areas that are as flashy (and the flashiness often correlates with
> complexity).

We need to collaborate on proposal writing, I think (which is why I suggested one-thread-per-proposal in a different email). In the past, it has mostly been one person writing the entire thing.

Show 12 quoted lines

>> There is one easy way to fight spam: don't expose a web-based editing
>> interface at all.  It's mainly going to be maintained by the
>> community, and we're all much more comfortable in our editors and git.
>> We can give the regulars direct commit access and ask the rest to
>> submit pull requests.  Make it cost pennies, so any of us can easily
>> afford it: just a cheap domain, DNS, and static HTML hosting.
>
> I'd be totally fine with that. You'd need to pick a static generator
> framework (I don't think it is a good idea for everybody to be writing
> raw html). I suspect kernel.org would be happy to host the static pages,
> but if not, GitHub can pick up the hosting tab (and we could probably do
> it as a subdomain under git-scm.com, too, if people want).

Ofcourse. Nobody wants to write raw HTML. Additionally, I'd love it if we could post new posts via email, since we already have the habit of writing emails.