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 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
> No, I'm against using the GitHub Wiki for neutrality reasons.
Fair enough. I have the same reservations.
> 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).
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