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 complexity). > 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). -Peff -- 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