Re: Google Summer of Code 2013 (GSoC13)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King wrote:
> 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.

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

>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]