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
- 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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html