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